A quick precision test

06032014, 02:11 PM
Post: #21




RE: A quick precision test
(06032014 01:51 AM)Gerson W. Barbosa Wrote: This is from an old Scientific American article, "How to handle numbers with thousands of digits, and why one might want to", by Fred Gruenberger (Computer Recreations, April 1984). ( "Come e perché trattare numeri con migliaia di cifre", in Le Scienze ) +1 for Fred Gruenberger, and the old Scientific American. 

06032014, 09:39 PM
Post: #22




RE: A quick precision test
(06032014 02:11 PM)everettr Wrote:(06032014 01:51 AM)Gerson W. Barbosa Wrote: This is from an old Scientific American article, "How to handle numbers with thousands of digits, and why one might want to", by Fred Gruenberger (Computer Recreations, April 1984). ( "Come e perché trattare numeri con migliaia di cifre", in Le Scienze ) Our university library had a subscription to Scientific American and lots of issues then. That's one of the few articles I still have a copy of. I hope they still have them. It might be cheaper to go there and scan the articles I am interested in than paying SciAm $7,99 each :) Gerson. 

06032014, 10:06 PM
(This post was last modified: 06032014 10:11 PM by Massimo Gnerucci.)
Post: #23




RE: A quick precision test
(06032014 09:39 PM)Gerson W. Barbosa Wrote:(06032014 02:11 PM)everettr Wrote: +1 for Fred Gruenberger, and the old Scientific American. I've got all "Le Scienze" issues from 1968 to 2008 on 2 DVDs, unfortunately not all sections are present, only main articles. However I found complete text online. This way is better, though... Greetings, Massimo +×÷ ↔ left is right and right is wrong 

06032014, 10:10 PM
Post: #24




RE: A quick precision test
(06032014 12:57 PM)Massimo Gnerucci Wrote: This one? That's the one. Shorter than I remember but priceless nonetheless. I'm probably mixing things up again with the come from.  Pauli 

06032014, 10:20 PM
Post: #25




RE: A quick precision test
(06032014 11:31 AM)Massimo Gnerucci Wrote:(06032014 11:24 AM)walter b Wrote: Quite natural, isn't it? I must have written no more than half a dozen COBOL programs as a student, but I do remember that sentence (which I liked very much, BTW). Back in the day I would occasionally change the ROM of my MSX computer in order to exchange dots and commas in numeric outputs). It was a pleasant surprise when I discovered the HP15C, a replacement to a TI59, had an equivalent of that builtin (ON/.). I had never bothered about decimal points in my previous calculators, but commas as thousands separators looked quite strange  there ought to have a way to change that. That was the first thing I looked for in the HP15C manual, I think (no, that was the second, the first one was the whereabouts of a hidden equals key :) Cheers, Gerson. 

06032014, 10:38 PM
Post: #26




RE: A quick precision test  
06042014, 05:07 AM
Post: #27




RE: A quick precision test
(06032014 10:38 PM)Didier Lachieze Wrote:(06032014 10:20 PM)Gerson W. Barbosa Wrote: It was a pleasant surprise when I discovered the HP15C, a replacement to a TI59, had an equivalent of that builtin (ON/.). I didn't know there was a Paname module for the HP 41C (but I remember the song, in a movie about Edith Piaf I watched recently :) CF 28 is fine too! (I didn't have a 41C back then) Gerson. 

06042014, 01:08 PM
Post: #28




RE: A quick precision test
(06032014 10:20 PM)Gerson W. Barbosa Wrote: Back in the day I would occasionally change the ROM of my MSX computer in order to exchange dots and commas in numeric outputs). I used a patched Turbo Pascal RTL file to make my preferred compiler do the same. ;) Quote:It was a pleasant surprise when I discovered the HP15C, a replacement to a TI59, had an equivalent of that builtin (ON/.). I had never bothered about decimal points in my previous calculators, but commas as thousands separators looked quite strange  there ought to have a way to change that. That's why the 41C offers every option you like: with and without separators (flag 29), with a comma or dot as the decimal marker (flag 28). After a master clear my first keystrokes always are "CF 28" to restore the decimal comma. BTW I would not care much about the "right" decimal marker if it was not hidden between two digits as it is nowadays. There were times when the dot/comma hat its own digit in the display, e.g. on the 67/97. I think this is much better than what we have on most calculators today. That's why I do not have a problem with numbers displayed in a fixed width font on a computer screen  the decimal marker is perfectly visible, both as a dot or as a comma. On the other hand I can hardy distinguish the dot/comma setting on a 34s. The marker simply is too small. That's why I usually turn the thousands separators off – in a number with four dots it's hard to tell which of them is the decimal marker. Dieter 

06042014, 01:23 PM
Post: #29




RE: A quick precision test
(06042014 01:08 PM)Dieter Wrote: On the other hand I can hardy distinguish the dot/comma setting on a 34s. The marker simply is too small. That's why I usually turn the thousands separators off – in a number with four dots it's hard to tell which of them is the decimal marker. That topic is going to be covered in a far friendlier way on the 43S. d:) 

06042014, 01:25 PM
(This post was last modified: 06042014 01:32 PM by Claudio L..)
Post: #30




RE: A quick precision test
(06032014 12:36 AM)Paul Dale Wrote: We always round to 16 or 34 digits when we return the result to the stack. These are the only precisions a user or a keystroke program can access. Unless you are coding numerics in C, this is all you get. Paul, EDIT: Nevermind, I just read the post from G. Barbosa, showing that WP34S matches exactly the results of newRPL. I'm not deleting the information below just for the record, but my post is pretty much useless from here on... except to actually validate that WP34S and newRPL are on the same page. I think he's onto something. Rounding should not kill so many digits. I just took the newRPL demo (shameless advertising: download the demo from http://sf.net/p/newrpl ) and did: Code:
674530.4707410845593826891847277722 (if I didn't make a mistake copying by hand the numbers) The "real" result at 34 digits is: 674530.4707410845593826891780297468 This is obtained from doing: Code:
The difference is 6.698E21, so there's 25 good digits out of the 34. Intermediate rounding only affected the last 9 digits. So the original poster might have a good point. newRPL does not use decNumber but uses mpdecimal, also correctly rounded and we also use a few digits more but all intermediate calculations are rounded to the user precision so the results from newRPL and WP34S should match exactly, as both should produce 34 correctly rounded digits on each intermediate calculation. I think his findings might be worth a second look. Claudio 

06042014, 01:33 PM
Post: #31




RE: A quick precision test
Claudio,
FYI, you're allowed to delete your post you rated as useless yourself. 

06042014, 01:38 PM
(This post was last modified: 06042014 01:52 PM by pito.)
Post: #32




RE: A quick precision test
(06042014 01:25 PM)Claudio L. Wrote: [quote='Paul Dale' pid='13135' dateline='1401755816'] Not sure whether doing 27 times x^2 or using Xpower2power27 is the same. Power functions are calculated in a different way usually (less precise I bet..). I've calculated the stuff with my dusty vanilla decnum code (DECNUMDIGITS 34) and get: Code: // 27x x^2 TEST Code: 27xTEST 

06042014, 01:42 PM
Post: #33




RE: A quick precision test  
06042014, 02:12 PM
Post: #34




RE: A quick precision test
And the same with DECNUMDIGITS 60:
Code: 27xTEST 

06042014, 02:17 PM
(This post was last modified: 06042014 02:20 PM by Claudio L..)
Post: #35




RE: A quick precision test
(06042014 01:38 PM)pito Wrote: Not sure whether doing 27 times x^2 or using Xpower2power27 is the same. Power functions are calculated in a different way usually (less precise I bet..). Regarding your suspicion that it's not the same: you are right, it's not. The power function is guaranteed to give you an accurate result with 34 good digits, for any 2 parameters (in this case, your guess that it's less precise is incorrect). Doing 2 ^ 27, the result is less than 34 digits, so it's exact (no rounding error). so 1.0000001 ^ (2^27) should give you an answer with all 34 digits correct, since both numbers are "exact" as given in the problem. I don't know how decNumber does it in particular, but in general powers with small integer exponents are handled by a sequence of multiplications, while powers of real numbers or large numbers are usually done through logarithms: Code: x^a = exp( a * ln(x) ) Which is usually very accurate, as ln() and exp() are both guaranteed to give you 34+GUARD good digits on any number you throw at them. If you assume that basic operations give you results that are guaranteed up to your user precision, your only source of error is the rounding of those results to your user precision. The less operations you perform the better, so you don't accumulate those rounding errors. In this case, if you do: Code: 1.0000001 LN 2 27 ^ * EXP Code: 1.0000001 2 27 ^ ^ but this is by pure chance (with this precision, this particular number behaves like this), since the intermediate rounded results of LN and * could've messed the last digit. Claudio 

06042014, 02:31 PM
(This post was last modified: 06042014 05:47 PM by pito.)
Post: #36




RE: A quick precision test
With 27x x^2 and with POW POW, DECNUMDIGITS 34:
Code: // 27x POW POW based TEST Code: 27xTEST And wolfram's alfa online (maybe the most precise) calculated with POWPOW: Code: 674530.470741084559382689178029746812844444143410342031742377327839017761756835646924185036948314117161449392236580649487823578911213711850826688459566614043388125378336496387788231656101312624670050466194146305337349976995456423843819302073708250892917760403115030579257091946625150900847950063719080001464820114313093498728408041488454981733591279031941696561625036530446399539623519795473743965573225426379607708298301765169283525997445575898149918290658791802903934344055702653738971... Code: 27x x^2 34dig 674530.4707410845593826891847277722 

06042014, 09:47 PM
Post: #37




RE: A quick precision test
(06042014 01:25 PM)Claudio L. Wrote: newRPL does not use decNumber but uses mpdecimal, also correctly rounded and we also use a few digits more but all intermediate calculations are rounded to the user precision so the results from newRPL and WP34S should match exactly, as both should produce 34 correctly rounded digits on each intermediate calculation. By using extra guard digits you get a double rounding step which can result in incorrectly rounded results. A quick example... If the true result of a computation is 123.456789 but our guard digit format only carries 4 digits, the guarded result will correctly be 123.5. If now, our returned result only has 3 digits, we'll get 124 which is incorrect. It should be 123. Sure this is contrived but the same can happen regardless of the number of guard digits. Double rounding is bad. Guard digits are good. Generally guard digits are more good than double rounding is bad, which is why they are used. However, getting a correctly rounded result is, in general, extremely difficult.  Pauli 

06042014, 10:09 PM
Post: #38




RE: A quick precision test
(06042014 02:17 PM)Claudio L. Wrote: The power function is guaranteed to give you an accurate result with 34 good digits, for any 2 parameters (in this case, your guess that it's less precise is incorrect). I very very much doubt this. Perhaps results with one ULP error but even then I doubt it is that good. The power function is a very difficult one to get right. The GNU C library implementation for 64 bit doubles, in bad cases, falls back to multiple precision calculations carrying over 1600 guard bits. I expect someone rather clever spent a lot of time and effort determining that number as an upper bound to guarantee correctness for the 53 mantissa bits in the result. Quote:I don't know how decNumber does it in particular, but in general powers with small integer exponents are handled by a sequence of multiplications, while powers of real numbers or large numbers are usually done through logarithms: Two points here:
A good rule of thumb to follow is to assume correct rounding for the four arithmetic operations and square root  these are mandated by the IEEE floating point standards these days. Everything else is close.  Pauli 

06052014, 01:18 AM
(This post was last modified: 06052014 01:19 AM by Claudio L..)
Post: #39




RE: A quick precision test
(06042014 10:09 PM)Paul Dale Wrote:(06042014 02:17 PM)Claudio L. Wrote: The power function is guaranteed to give you an accurate result with 34 good digits, for any 2 parameters (in this case, your guess that it's less precise is incorrect). I don't know that much, but the documentation of mpdecimal says the error is 1 ULP, so we use 9 extra digits and then we round, so the 'bad rounding' case would have to be in the form 999999995 in order for the 1 ULP error to give a badly rounded result. Notice that I said 'accurate digits' not 'correctly rounded'. The 1 ULP case may still happen, with a chance of 1 in 10^9. (06042014 10:09 PM)Paul Dale Wrote:Quote:I don't know how decNumber does it in particular, but in general powers with small integer exponents are handled by a sequence of multiplications, while powers of real numbers or large numbers are usually done through logarithms: I agree, but "close" as in the last digit may be off by 1 due to rounding and only in some corner cases (like 1 in 10^9 chance), on most numbers you should get the right value. 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. Claudio 

06052014, 02:00 AM
Post: #40




RE: A quick precision test
(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. I doubt that the 1600 bits (not digits) is actually required in reality. I suspect rather, that a proof was devised that this was sufficient for all possible input values rather than finding the absolute worst case. There has been a fair bit of work done on actually locating the worst cases in the past few years. A quick check on google leads to two links: For binary: http://hal.inria.fr/inria00072594/PS/RR4044.ps For decimal: http://perso.enslyon.fr/damien.stehle/d...malexp.pdf There are plenty of others a search away. The example at the bottom of the second page of the second paper is interesting. Forty seven correct decimal digits being required to correctly round towards zero  34 plus 9 guards won't get this right and this is only a 16 digit input, a 34 digit one would be worse. As I've said many times, "numerical analysis is hard".  Pauli 

« Next Oldest  Next Newest »

User(s) browsing this thread: