If pi is so accurate why it's not producing that accurate result. Classic List Threaded 10 messages Open this post in threaded view
|

If pi is so accurate why it's not producing that accurate result.

 I checked pi is almost accurate to 1000 digits. WoWww. But in this cases, >> cos(pi/2) ans =    6.1232e-17 >> tan(pi/2) ans =    1.6331e+16 the result is not that accurate,not even close to infinite or zero. Can anyone tell why so? -- Sent from: http://octave.1599824.n4.nabble.com/Octave-General-f1599825.html
Open this post in threaded view
|

Re: If pi is so accurate why it's not producing that accurate result.

 ________________________________ From: Dildar Sk <[hidden email]> To: [hidden email] Sent: Friday, March 23, 2018 10:06 PM Subject: If pi is so accurate why it's not producing that accurate result. I checked pi is almost accurate to 1000 digits. WoWww. But in this cases, >> cos(pi/2) ans =    6.1232e-17 >> tan(pi/2) ans =    1.6331e+16 the result is not that accurate,not even close to infinite or zero. Can anyone tell why so? -- Sent from: http://octave.1599824.n4.nabble.com/Octave-General-f1599825.html----------------------------------------------------------------------------- "the result is not that accurate,not even close to infinite or zero" - huh ? Max value of 'cos' is 1; 1e-17 means -340db; 6.1232e-17 is better than -320db. So, what else do you want ? Do you at all understand how floating point math works and how 'sin' and 'cos' are implemented in SW and HW ? --Sergei.
Open this post in threaded view
|

Re: If pi is so accurate why it's not producing that accurate result.

 In reply to this post by Dildar Sk On Fri, Mar 23, 2018, 3:05 PM Dildar Sk, <[hidden email]> wrote:I checked pi is almost accurate to 1000 digits. WoWww. But in this cases, >> cos(pi/2) ans =    6.1232e-17 >> tan(pi/2) ans =    1.6331e+16 the result is not that accurate,not even close to infinite or zero. Can anyone tell why so? Pi is known to well over millions of digits. But our software cannot store millions of digits so we have to discard most of the digits and only keep a few at the front end. If you discard some digits then there can be an error produced. What you are seeing is just a result of chopping off some of the digits and seeing what's left. -- Sent from: http://octave.1599824.n4.nabble.com/Octave-General-f1599825.html
Open this post in threaded view
|

Re: If pi is so accurate why it's not producing that accurate result.

 In reply to this post by Sergei Steshenko Sorry, I know it's very hard to deal with floating point arithmetic. But I am just asking why tan(pi/2) is not close to infinity.Though there in Octave max is 10^308 but it producing 10^17 something. And I wonder how pi is so accurate then!! -- Sent from: http://octave.1599824.n4.nabble.com/Octave-General-f1599825.html
Open this post in threaded view
|

Re: If pi is so accurate why it's not producing that accurate result.

 Doug, I got that now.So that chop off makes this result. But can we expect little more accuracy? -- Sent from: http://octave.1599824.n4.nabble.com/Octave-General-f1599825.html
Open this post in threaded view
|

Re: If pi is so accurate why it's not producing that accurate result.

 In reply to this post by Dildar Sk On Fri, Mar 23, 2018 at 3:16 PM, Dildar Sk wrote:Sorry, I know it's very hard to deal with floating point arithmetic. But I am just asking why tan(pi/2) is not close to infinity.Though there in Octave max is 10^308 but it producing 10^17 something. And I wonder how pi is so accurate then!!you are getting into some of the subtle details of floating point arithmetic. 10^308 is on the order of the largest normalized real number. the 10^17 deals with relative precision.  see the following:https://www.maths.unsw.edu.au/sites/default/files/MatlabSelfPaced/lesson2/MatlabLesson2_Constants.html
Open this post in threaded view
|

Re: If pi is so accurate why it's not producing that accurate result.

 On Fri, Mar 23, 2018 at 3:44 PM, Nicholas Jankowski wrote:On Fri, Mar 23, 2018 at 3:16 PM, Dildar Sk wrote:Sorry, I know it's very hard to deal with floating point arithmetic. But I am just asking why tan(pi/2) is not close to infinity.Though there in Octave max is 10^308 but it producing 10^17 something. And I wonder how pi is so accurate then!!you are getting into some of the subtle details of floating point arithmetic. 10^308 is on the order of the largest normalized real number. the 10^17 deals with relative precision.  see the following:https://www.maths.unsw.edu.au/sites/default/files/MatlabSelfPaced/lesson2/MatlabLesson2_Constants.html perhaps a slightly more complete explanation:https://www.mathworks.com/help/matlab/matlab_prog/floating-point-numbers.html
Open this post in threaded view
|

Re: If pi is so accurate why it's not producing that accurate result.

 On Fri, Mar 23, 2018 at 3:57 PM, Nicholas Jankowski wrote:On Fri, Mar 23, 2018 at 3:44 PM, Nicholas Jankowski wrote:On Fri, Mar 23, 2018 at 3:16 PM, Dildar Sk wrote:Sorry, I know it's very hard to deal with floating point arithmetic. But I am just asking why tan(pi/2) is not close to infinity.Though there in Octave max is 10^308 but it producing 10^17 something. And I wonder how pi is so accurate then!!procrastination tangent. so here are some (incomplete) details I've gleaned over time on floating point numbering. someone better at this can correct my mistakes:so none of our responses really explained why infinity stopped at 1.6331e+016, and 'zero' at ~6e-17. since it _can_ represent numbers closer to 0 and inf, why doesn't it?here's another conversation about realmin, realmax, and eps:https://blogs.mathworks.com/loren/2009/08/20/precision-and-realmax/and a good explanation of IEEE Standard 754 floating point numbers:http://steve.hollasch.net/cgindex/coding/ieeefloat.htmlSo, floating point can represent very large numbers (10^308), but the relative precision of the floating point math changes with the magnitude of the number you're working with.epsval = eps(x) gives you the smallest discernible increment around the value x.  i.e., epsval is the smallest number where epsval+x doesn't round back down to xeps by itself returns the eps around 1.0, and is what we usually consider machine precision, which is 2^-52 on my machine.eps(1.0) = 2.2204e-16log2(eps(1.0) = -52as the IEEE explanation above states, this value corresponds to 64bits (double precision) floating point assignment: 1 bit for sign, 11 bits for exponent, leaving 52bits for the base.  So a single bit change represents a value change of 2^-52 about 1.0.  Larger and smaller values of x will have larger and smaller values of eps when the change in exponent cause a shift in the magnitude of the smallest bit.  Octave doesn't list this, but the first article above and the Matlab help for eps give eps at different values. some of these from small to large are:>> a = realmin, eps(a), log2(eps(a))a =   2.2251e-308ans =   4.9407e-324ans = -1074>> a = eps, eps(a), log2(eps(a))a =   2.2204e-016ans =   4.9304e-032ans = -104>> a=0.1,eps(a),log2(eps(a))a =  0.10000ans =   1.3878e-017ans = -56>> a=1,eps(a),log2(eps(a))a =  1ans =    2.2204e-016ans = -52>> a=10^2,eps(a),log2(eps(a))a =  100ans =   1.4211e-014ans = -46>> a=10^10,eps(a),log2(eps(a))a =   1.0000e+010ans =   1.9073e-006ans = -19>> a=10^15,eps(a),log2(eps(a))a =   1.0000e+015ans =  0.12500ans = -3>> a=10^20,eps(a),log2(eps(a))a =   1.0000e+020ans =  16384ans =  14>> a=realmax,eps(a),log2(eps(a))a =   1.7977e+308ans =   1.9958e+292ans =  971NOW, more germane to your question, why does octave/matlab stop at ~10^-17 and ~10^17 with pi?well:>> a=cos(pi/2),eps(a),log2(eps(a))a =   6.1230e-017ans =   1.2326e-032ans = -106>> a=tan(pi/2),eps(a),log2(eps(a))a =   1.6331e+016ans =  2ans =  1on the high side, 1.6331e-16 is the largest value where the smallest discernible change reaches 2^1.  in the former, it's close to eps(1)/4. I believe (although I haven't found a simple reference to confirm, so would love confirmation) that these are the smallest and largest values that can be represented with 52 fractional bits while including the unit value.nickj