A quick precision test

06052014, 11:03 AM
Post: #41




RE: A quick precision test
(06052014 02:00 AM)Paul Dale Wrote:(06052014 01:18 AM)Claudio L. Wrote: I'd love to test some corner cases to see how the algorithms behave (like that case that needs 1600 digits, do you have any links to good material on this subject?). I did some tests of my own but I don't know what the corner cases are. I'd like to have some literature where they list cases that I can use to stress the algorithms and see the results. Thanks for the links! I will never understand this obsession for correct rounding. When rounding, you are introducing an error, so why obsess too much about it? Case in point: If I use 9 extra digits for internal calcs, then my result will only be affected by double rounding if my number is of the form: nnnnn4999999995 Where nnnnn is digits we want to keep, the 4999 are my extra digits, and the last 5 belongs to the real number, is not stored anywhere and we don't really know it. That number could be a 5 or more. So when rounding the higher precision numer, we'd turn the 49999999... into 500000.. causing the last digit to go off by one (insert your horror face here!). But the magnitude of the error is: With "correct" rounding e = .4999999995 and with our "bad" result e = 0.5000000005 The last digit is not what we expected, so what? the number is still accurate within ~0.5 ULP and it will only happen 1 in 10^digits (when all 9 extra digits are exactly 499999999). Honestly, I don't lose too much sleep about it, just because a mathematician doesn't get his way every now and then doesn't mean we should all go crazy about it. But I'll test the algorithms and see what happens. Thanks again for the links. Claudio 

06052014, 11:23 AM
(This post was last modified: 06052014 11:23 AM by Dieter.)
Post: #42




RE: A quick precision test
(06052014 11:03 AM)Claudio L. Wrote: The last digit is not what we expected, so what? the number is still accurate within ~0.5 ULP This exactly is the point: there is no way to be absolutely sure the error does not exceed half a ULP. Not even HP can or will guarantee this level of accuracy. A nice overview on this can be found in the HP15C Advanced Functions Handbook. That's why my personal accuracy target for "machince precision" is 0,6 ULP or 1 unit in the n+1st significant digit. This is what can be expected on a 15C or 41C for the trig functions, and if it's good enough there, it's good enough for me either. BTW there are much larger errors in other functions on regular HP calculators that can be off by several ULP, or the error may even spoil last two digits. So ±0,6 or sometimes even ±1 ULP is fine by me. Dieter 

06052014, 12:06 PM
Post: #43




RE: A quick precision test
(06052014 11:03 AM)Claudio L. Wrote: If I use 9 extra digits for internal calcs, then my result will only be affected by double rounding if my number is of the form: There are other rounding cases. What about nnnnm5000000001 when m is odd and you are rounding to even? Or nnnnn0000000001 when you are rounding towards +infinity? Assuming you support rounding modes of course. Agreed, the chance of being incorrect  if your internal result is correct  is low but it is still there. Correct rounding is a worthwhile, if somewhat quixotic, goal. One ULP is far more achievable. Are you sure all of your guard digits are correct or even all the digits in your result? In general they (the guard digits) won't all be. There are many pitfalls for the unwary here. Even changing the order of operations can cause problems. You need to be amazingly careful to get all digits correct, if indeed this is even possible (which it isn't in general). As an example (which isn't related to rounding), what does COS(1.57079632679489661923132169163975144) equal? Is it 2.09858469968755291048739331660132323e36 or something different? I cheated here and downloaded your (rather nice BTW) newRPL demo and it gets the last thirteen digits incorrect. TAN of the same value loses fourteen digits and this answer is a huge number rather than something very tiny. My original 34S test case was COS(1.570796326794896619231321691639751) where newRPL gets the last ten digits incorrect  the 34S gets more digits incorrect here. With more memory available, I'd fix this.  Pauli 

06052014, 08:49 PM
(This post was last modified: 06052014 09:08 PM by pito.)
Post: #44




RE: A quick precision test
FYI  a quick test (27x x^2) done in the shop with cheapo Canon X Mark I Pro:
Code: 674530.4707 

06052014, 09:07 PM
Post: #45




RE: A quick precision test
(06052014 08:49 PM)pito Wrote: FYI  a quick test done in the shop with cheapo Canon X Mark I Pro: No idea what you're referring to. BTW, after some 40 posts, would you please learn to use <Quote> to indicate the post you're responding? Thanks in advance. d:/ 

06052014, 09:08 PM
Post: #46




RE: A quick precision test
(06052014 12:06 PM)Paul Dale Wrote: As an example (which isn't related to rounding), what does COS(1.57079632679489661923132169163975144) equal? Is it 2.09858469968755291048739331660132323e36 or something different? I cheated here and downloaded your (rather nice BTW) newRPL demo and it gets the last thirteen digits incorrect. TAN of the same value loses fourteen digits and this answer is a huge number rather than something very tiny. 2 things: the first demo came out with a bug that returns the TAN of PI/2Arg instead of TAN(arg) (among several other bugs I've already fixed), I'll publish a new demo this weekend, now with DOLIST [end of shameless advertising]. I did your test: COS(1.57079632679489661923132169163975144) and I got 2.098584699687552910487472296153908 What makes you think those digits are incorrect? I did the same with preccalc (from sourceforge, very nice calc for windows), and it gives me the exact same value. I've also increased precision to many more digits (keeping the argument at 36 digits they way you have it) and still the same result. newRPL does lose digits, of course, it's part of the implementation, but in this case, your angle is in the order of 10^35 difference with PI/2, so I'm losing 35 digits, but you can only see them at maximum precision (2016 digits). I for instance ran it at 201635=1981 digits precision and still gave me identical results as preccalc, up to the very last digit. If I run it at 2016 digits, I can clearly see the last 35 digits are garbage. I've also checked with Wolfram Alpha, and... exact same number! (I checked up to 36 digits only, the others are left to the reader to compare...) hint: Alpha won't give you more than the number of digits you input, so it will show only 5 digits unless you add lots of trailing zeros to the input argument. I also tried your COS() case with 34 digits and once more, it agrees with preccalc and Alpha on all 34 digits. I think you are taking for granted some results as "correct" that are perhaps not too good? Claudio 

06052014, 09:13 PM
(This post was last modified: 06052014 09:27 PM by pito.)
Post: #47




RE: A quick precision test
(06052014 09:07 PM)walter b Wrote:(06052014 08:49 PM)pito Wrote: FYI  a quick test done in the shop with cheapo Canon X Mark I Pro: Dear Walter, I've just added an info to the topic I started. BTW, you contributed to this thread with 4 absolutely unrelated postings 

06052014, 09:21 PM
(This post was last modified: 06052014 09:22 PM by Mark Hardman.)
Post: #48




RE: A quick precision test
(06052014 09:13 PM)pito Wrote: Dear Walter, I've just added an info to the topic I've started. Franz, is that you? Are you nymshifting now? Mods, feel free to delete this. But it just has to be said. Ceci n'est pas une signature. 

06052014, 09:25 PM
Post: #49




RE: A quick precision test
(06052014 12:06 PM)Paul Dale Wrote: There are other rounding cases. What about nnnnm5000000001 when m is odd and you are rounding to even? Or nnnnn0000000001 when you are rounding towards +infinity? Assuming you support rounding modes of course. Yes, there's one case for each rounding mode, so it's still 1 in 10^9 chance no matter which mode you select. (06052014 12:06 PM)Paul Dale Wrote: Agreed, the chance of being incorrect  if your internal result is correct  is low but it is still there. Correct rounding is a worthwhile, if somewhat quixotic, goal. One ULP is far more achievable. No, I cannot guarantee that all my guard digits are all correct, and that's one more reason not to obsess about rounding. As long as the most significant of my guard digits is good, there's only 0.5 ULP worstcase error (if I round the last digit up or down incorrectly). On the other hand, when I implemented transcendentals, I thought it this way: * The user should have 2000 good digits, that was my target. Since the library works in groups of 9 digits, you actually get 2007 (multiple of nine). * For me to be able to get guard digits, I calculated all the CORDIC constants with 2016 digits (9 digits more). * In the CORDIC loop, I set the precision to 9 digits more (2025) for all intermediate operations. It may seem dumb, because the constants have only 2016, but it actually helps get me a few more good digits. With this, I can get transcendentals correct to the last digit that will be displayed to the user on all the test cases I tried (except the ones where you lose precision, like your COS(near PI) case, but that comes from the argument, not the algorithm). Claudio 

06052014, 10:09 PM
Post: #50




RE: A quick precision test
(06052014 09:08 PM)Claudio L. Wrote: I've also checked with Wolfram Alpha, and... exact same number! (I checked up to 36 digits only, the others are left to the reader to compare...) When I do this on Wolfram Alpha, which is usually my gold standard for accuracy I get the numbers I quoted. This is the query I used. Quote:hint: Alpha won't give you more than the number of digits you input, so it will show only 5 digits unless you add lots of trailing zeros to the input argument. It will if you ask for them  Pauli 

06052014, 10:20 PM
Post: #51




RE: A quick precision test
(06052014 09:25 PM)Claudio L. Wrote: With this, I can get transcendentals correct to the last digit that will be displayed to the user on all the test cases I tried (except the ones where you lose precision, like your COS(near PI) case, but that comes from the argument, not the algorithm). The COS example I gave can be calculated correctly. The argument isn't the issue  it is represented exactly in the floating point number system. It really is the algorithm causing the loss. Witness that there are several libraries available that handle the equivalent bad case properly for binary arithmetic GNU's libc, MPFR are just two.  Pauli 

06062014, 12:57 AM
Post: #52




RE: A quick precision test
(06052014 10:09 PM)Paul Dale Wrote:(06052014 09:08 PM)Claudio L. Wrote: I've also checked with Wolfram Alpha, and... exact same number! (I checked up to 36 digits only, the others are left to the reader to compare...) Huh? The result given by alpha is different if you ask "with 72 decimal digits" or if you add 36 trailing zeroes to the number. I just did: COS(1.57079632679489661923132169163975144) with 72 decimal digits (I didn't know you could write that in "human words", that's cool! if it only gave good answers...) And I also did COS(1.57079632679489661923132169163975144000000000000000000000000000000000000) (36 zeroes, for a total of 72 decimal digits, so it should be the same...right?) The result in each case is: 2.098584699687552910487393316601323231×10^36 2.09858469968755291048747229615390820 × 10^36 What's going on? is it making the digits up or what? The second answer agrees with newRPL and preccalc, which is why I "conveniently" choose to believe that one. I say "conveniently" because it agrees with my code, not because I know it for a fact to be correct. I used to trust the results from Alpha blindly (and from the past few posts, I can tell you too). Now I just don't know what to believe, and neither should you from now on. Claudio 

06062014, 01:03 AM
Post: #53




RE: A quick precision test
(06052014 10:20 PM)Paul Dale Wrote:(06052014 09:25 PM)Claudio L. Wrote: With this, I can get transcendentals correct to the last digit that will be displayed to the user on all the test cases I tried (except the ones where you lose precision, like your COS(near PI) case, but that comes from the argument, not the algorithm). In my case it is not the algorithm, it's the argument. CORDIC does not converge for angles > 1 radian, so I compute that cos() as sin(PI/2alpha). Here's where I loose the digits: My PI constant only has 2016 digits, so if alpha = PI/21e35, my substraction PI/2(PI/21e35) gives me 1e35 with only 201635 accurate digits. That's where I'm losing my 35 digits. I could get them back only by storing PI/2 with twice the system precision, so PI/21ULP would give me (2016*22016)=2016 good digits. Claudio 

06062014, 01:15 AM
Post: #54




RE: A quick precision test
(06062014 12:57 AM)Claudio L. Wrote: I used to trust the results from Alpha blindly (and from the past few posts, I can tell you too). Now I just don't know what to believe, and neither should you from now on. Paul, I got to give you credit: when you said it's hard to write good numeric code, you were right: if the mighty Wolfram can't get it right what's left for the rest of us. Claudio 

06062014, 01:35 AM
(This post was last modified: 06062014 11:20 AM by Paul Dale.)
Post: #55




RE: A quick precision test
(06062014 12:57 AM)Claudio L. Wrote: I used to trust the results from Alpha blindly (and from the past few posts, I can tell you too). Now I just don't know what to believe, and neither should you from now on. I'm very surprised by this too & I'm definitely going to be less trusting in the future. Can anyone try this out on mathematica? I also use http://keisan.casio.com/ for high precision computations but it doesn't cope with these cases well. The UNIX program bc is also capable of simple functions, although it can be slow. It gives at 1000 decimals: Code: .0000000000000000000000000000000000020985846996875529104874722961539\ The digits don't change working to 10000 digits. The code is calculating cos(x) = sin(x + pi/2) and it is using 1.2 times the digits (1200 or 12000 respectively). As for, sin(x) it is using a Taylor series with a couple of additional digits. This matches the values you're getting and your result from Wolfram.  Pauli 

06062014, 01:46 AM
Post: #56




RE: A quick precision test
(06062014 01:03 AM)Claudio L. Wrote: In my case it is not the algorithm, it's the argument. CORDIC does not converge for angles > 1 radian, so I compute that cos() as sin(PI/2alpha). Sounds like the algorithm. As in you need a different way to compute cos cos(x) = sin(x + pi/2) is generally considered an okay transformation from memory. Taylor series also converge well if you range reduce the argument suitably  aim for pi/4 or less so that the first term in the series is the most significant.  Pauli 

06062014, 11:16 AM
(This post was last modified: 06062014 12:17 PM by pito.)
Post: #57




RE: A quick precision test
(06062014 12:57 AM)Claudio L. Wrote: .. This is with N trailing zeros after the last "4": Code: Block[{$MinPrecision = 120}, N[Cos[1.57079632679489661923132169163975144], 130]] 

06062014, 12:04 PM
(This post was last modified: 06062014 12:07 PM by Claudio L..)
Post: #58




RE: A quick precision test
(06062014 11:16 AM)pito Wrote:(06062014 12:57 AM)Claudio L. Wrote: .. 00 2.09858469968759412260293728493047158318234204531375910645959950911100\ 455087648653787132935200077099580084905028343200684*10^36 000 2.09858469968759412260293728493047158318234204531375910645959950911100\ 455087648653787132935200077099580084905028343200684*10^36 0000 2.09858469968755291048739331660132323148430199128683081113869140777373\ 772224262464875860587211945559288771556897645713391*10^36 00000 2.09858469968755291048739331660132323148430199128683081113869140777373\ 772224262464875860587211945559288771556897645713391*10^36 .. 000000000000000 2.09858469968755291048747229615389016692898991768376891330235232863694\ 116237367172368967960981143453674385805543780051439*10^36 I put the "good" digits in BOLD. The last one seems to give good 33 digits (well, the last one off by 1 per rounding, but let's not start on that subject again...) I think it was Paul's error: he asked Alpha "with 120 decimal digits", he should've written "with 120 decimal correctly calculated and correctly rounded digits". See? it was human error, not Alpha. Claudio 

06062014, 12:19 PM
(This post was last modified: 06062014 01:05 PM by pito.)
Post: #59




RE: A quick precision test
Quote:I've added a result (see above)  maybe you'll get the 34th digit(06062014 12:04 PM)Claudio L. Wrote: The last one seems to give good 33 digits (well, the last one off by 1 per rounding, but let's not start on that subject again...) 2.098584699687552910487472296153890166928989917683768.. 2.098584699687552910487472296153908203143104499314016.. 

06062014, 10:55 PM
(This post was last modified: 06062014 10:55 PM by Paul Dale.)
Post: #60




RE: A quick precision test
(06062014 12:04 PM)Claudio L. Wrote: I think it was Paul's error: he asked Alpha "with 120 decimal digits", he should've written "with 120 decimal correctly calculated and correctly rounded digits". See? it was human error, not Alpha. I understand my mistake now Alpha padded the result with semirandom digits just like I asked for.  Pauli 

« Next Oldest  Next Newest »

User(s) browsing this thread: 1 Guest(s)