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 |
________________________________ 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. |
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. |
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 |
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 |
In reply to this post by Dildar Sk
On Fri, Mar 23, 2018 at 3:16 PM, Dildar Sk <[hidden email]> wrote: Sorry, 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 |
On Fri, Mar 23, 2018 at 3:44 PM, Nicholas Jankowski <[hidden email]> wrote:
perhaps a slightly more complete explanation: https://www.mathworks.com/help/matlab/matlab_prog/floating-point-numbers.html |
On Fri, Mar 23, 2018 at 3:57 PM, Nicholas Jankowski <[hidden email]> wrote:
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/lo and a good explanation of IEEE Standard 754 floating point numbers: http://steve.hollasch.net/ So, 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 x eps 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-16 log2(eps(1.0) = -52 as 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-308 ans = 4.9407e-324 ans = -1074 >> a = eps, eps(a), log2(eps(a)) a = 2.2204e-016 ans = 4.9304e-032 ans = -104 >> a=0.1,eps(a),log2(eps(a)) a = 0.10000 ans = 1.3878e-017 ans = -56 >> a=1,eps(a),log2(eps(a)) a = 1 ans = 2.2204e-016 ans = -52 >> a=10^2,eps(a),log2(eps(a)) a = 100 ans = 1.4211e-014 ans = -46 >> a=10^10,eps(a),log2(eps(a)) a = 1.0000e+010 ans = 1.9073e-006 ans = -19 >> a=10^15,eps(a),log2(eps(a)) a = 1.0000e+015 ans = 0.12500 ans = -3 >> a=10^20,eps(a),log2(eps(a)) a = 1.0000e+020 ans = 16384 ans = 14 >> a=realmax,eps(a),log2(eps(a)) a = 1.7977e+308 ans = 1.9958e+292 ans = 971 NOW, 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-017 ans = 1.2326e-032 ans = -106 >> a=tan(pi/2),eps(a),log2(eps(a) a = 1.6331e+016 ans = 2 ans = 1 on 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 |
The answer is truly helpful and on the other side to the point.
Thanks NickJ. -- Sent from: http://octave.1599824.n4.nabble.com/Octave-General-f1599825.html |
Here is another thing to think about. Let us denote by tpi the true value of pi, and by npi the numerical value of pi in IEEE double precision arithmetic. Now we have the identities cos(tpi/2-x) = sin(x) tan(tpi/2-x) = cot(x) = 1/tan(x). Now npi/2 = tpi/2-x where x is of the order of 1e-16. And for small x, we have the approximation (here ~= denotes approximately equal to): sin(x) ~= x tan(x) ~= x. So we obtain cos(npi/2) ~= (tpi-npi)/2 tan(npi/2) ~= 2/(tpi/npi) And this is exactly what you get. From: Help-octave <help-octave-bounces+stephen=[hidden email]> on behalf of Dildar Sk <[hidden email]>
Sent: Saturday, March 24, 2018 12:45:25 AM To: [hidden email] Subject: Re: If pi is so accurate why it's not producing that accurate result. The answer is truly helpful and on the other side to the point.
Thanks NickJ. -- Sent from: http://octave.1599824.n4.nabble.com/Octave-General-f1599825.html |
Free forum by Nabble | Edit this page |