WP 34S vs. DM42 decimal128 differences?

03202018, 09:15 AM
(This post was last modified: 03272018 09:51 AM by rkf.)
Post: #1




WP 34S vs. DM42 decimal128 differences?
Today I stumbled about a footnote in Walter's WP 34S Owner's manual, where at Page 319 the result of the Calculator Forensics Test is mentioned. To my big surprise, the DP difference between the test result, and 9, is
for WP 34S: 6.2465E29 for DM42: 6.2466E29 But why the differerence of 1 ULP?? For the other example (1.0000001^2^27), there isn't any difference between the two models, BTW. 

03202018, 09:27 AM
Post: #2




RE: WP 34S vs. DM42 decimal128 differences?
(03202018 09:15 AM)rkf Wrote: Today I stumbled about a footnote in Walter's WP 34S Owner's manual, where at Page 319 the result of the Calculator Forensics Test is mentioned. To my big surprise, the DP difference between the test result, and 9, is Both calculators use 34digit precision, but this does not mean that they return the same results. The trig functions may be implemented differently, and there is no claim (at least for the 34s) that all 34 digits are correct. The 34s also has different round modes that can be set, which will affect the result as well. Dieter 

03202018, 09:35 AM
Post: #3




RE: WP 34S vs. DM42 decimal128 differences?
I believe the 34S is correct here. Free42 uses the Intel decimal library which rounds some functions incorrectly.
Well, the 34S used to get this correct but there were some changes to the trig code to better handle cases near multiples of \( \frac{\pi}{2} \), it is possible they threw it off. Pauli 

03262018, 09:51 PM
Post: #4




RE: WP 34S vs. DM42 decimal128 differences?
This is addressed to Pauli:
I've noticed that sin (pi radians) in doubleprecision mode on the WP34S is only correct to 17 significant figures. This disturbs me more than I would have expected (given that I normally have the calculator set to give me answers to 4 sf only!). If I change SINCOSDIGITS in decn.c to 69, all calculated digits are correct. Trig functions are slower (more so in double precision than in single precision). If I use 69 digits in the function sincosTaylor() when the calculator is in double precision mode, but 39 digits in single precision, I seem to get the best of both worlds  correct answers in both single and double precision, with no slowdown in singleprecision mode. Is this a change worth making (once I've done some more extensive testing, and looked at the code for tan x as well)? Or is there a downside other than speed to using these extra digits? Nigel (UK) 

03262018, 10:43 PM
Post: #5




RE: WP 34S vs. DM42 decimal128 differences?
(03262018 09:51 PM)Nigel (UK) Wrote: Is this a change worth making (once I've done some more extensive testing, and looked at the code for tan x as well)? Or is there a downside other than speed to using these extra digits? I'd be concerned about overflowing the stack in other functions that call this. E.g. the gamma code can call this and gamma in turn is called from the statistical routines which are close to the limit already. Using a smaller number of digits in single precision mode might also fall awry of this function's use elsewhere. If later digits carry an error they could cascade into the first sixteen. I'll have to have a think about it... Pauli 

03272018, 06:10 AM
Post: #6




RE: WP 34S vs. DM42 decimal128 differences?
(03262018 09:51 PM)Nigel (UK) Wrote: This is addressed to Pauli: Although I'm not Pauli but the original poster, I don't get the point here. Typing in Rad mode pi sin gives on both WP 34S DBLON, and DM42, a result of about 1.158E34. For me as a plain user this result seems to have nevertheless 34 significant figures, all of them zeroes (one before the decimal point, and 33 thereafter). Or do you compare the (exact) result of taking sin of a number, which is exactly pi rounded to 34 significant figures (thus to be expected in the ballpark around +/ 1E34) with the result the calculator gives, and then 1.158028306006248941790250554076922E34 itself is only correct to 17 figures? But that would be no problem at all for me. 

03272018, 07:58 AM
Post: #7




RE: WP 34S vs. DM42 decimal128 differences?
(03272018 06:10 AM)rkf Wrote: Or do you compare the (exact) result of taking sin of a number, which is exactly pi rounded to 34 significant figures (thus to be expected in the ballpark around +/ 1E34) with the result the calculator gives, and then 1.158028306006248941790250554076922E34 itself is only correct to 17 figures? But that would be no problem at all for me. I'm counting significant figures from the first nonzero digit  i.e., what you say above. I agree that it isn't likely to be a problem in any realworld application of the calculator. However, given that the WP34S has a doubleprecision mode it would be nice if the result was also correct to this level of precision, so long as this can be done without breaking the calculator's behaviour elsewhere. If you calculate sin (3.1415926536) on the HP28S (for example) you will get an answer correct to 12 nonzero significant digits, and Pauli has already adjusted the WP34S code to get cos (pi/2) (which is a similar case) correct to 34 sf. Most of the time the trig functions are correct to this level of precision, so trying to bring sin (pi) up to the same standard isn't unreasonable. I think it would be nice to fix it, if it can be fixed. Nigel (UK) 

03272018, 08:22 AM
Post: #8




RE: WP 34S vs. DM42 decimal128 differences?
(03272018 07:58 AM)Nigel (UK) Wrote: ... I'm counting significant figures from the first nonzero digit  i.e., what you say above. ... OK  thanks for the clarification! BTW, this very situation is discussed in detail at p. 184 of the HP15C Advanced Functions Handbook (although for the HP15C's 10 shown, and 13 internal digits  thus giving, depending from interpretation, either ten, or three significant digits). Since the WP 34S, and DM42 behave with respect to sin(pi) in complete accordance with the HP manual cited above, I'm fine with the status quo. :) 

03272018, 09:42 AM
Post: #9




RE: WP 34S vs. DM42 decimal128 differences?  
03292018, 04:03 PM
Post: #10




RE: WP 34S vs. DM42 decimal128 differences?
To Pauli, and anyone else interested in this:
I've got full precision working correctly with just one 69digit decNumber  x, in cvt_2rad_sincos. sincosTaylor itself isn't changed; its arguments are still pointers to SINCOSdigit decNumbers and the calculations in it are carried out to this precision. I divide radian arguments to cvt_2rad_sincos by \(2\pi\) to 69digit precision, and then do range reduction as with degrees and grads using fractions of a full circle as the thresholds. This means that any radian arguments that have a very small sine or cosine are mapped onto angles near zero, and so 69digit precision isn't needed to calculate these functions correctly. I've included the constant 0.125 in consts.h and compile_consts.c for use as the \(45^\circ\) threshold. I don't know whether the memory requirements will still be a problem. I've attached the modified source files in case you want to try them out yourself  if you don't, or you have a better approach of your own, that's fine as well! Nigel (UK) 

03292018, 11:46 PM
Post: #11




RE: WP 34S vs. DM42 decimal128 differences?
An interesting approach, one I had considered when I added the range reduction to these functions. My concern, then and now, is that e.g. \( \frac{\pi}4  x \) cannot be represented exactly and that this could change the result in some cases. You are dividing by \( 2\pi \) so the later range reduction will be exact, but this division step and the later inverse would be where the equivalent error occurs.
It is possible that at some level of extended precision, the errors become insignificant. Determining and proving this wouldn't be trivial. It's quite a difficult problem Still, it is an approach that's worth chasing. Pauli 

03302018, 12:11 PM
Post: #12




RE: WP 34S vs. DM42 decimal128 differences?
(03292018 11:46 PM)Paul Dale Wrote: An interesting approach, one I had considered when I added the range reduction to these functions. My concern, then and now, is that e.g. \( \frac{\pi}4  x \) cannot be represented exactly and that this could change the result in some cases. You are dividing by \( 2\pi \) so the later range reduction will be exact, but this division step and the later inverse would be where the equivalent error occurs. I'm sure that I'm missing some of the subtleties but the situation doesn't seem too bad to me.
Incidentally, calculating \(\sin(\pi)\) with a 34digit value of \(\pi\), using newRPL with 34 digits of precision, gives an answer also correct to 34 digits. Well done Claudio! Nigel (UK) 

03302018, 04:19 PM
Post: #13




RE: WP 34S vs. DM42 decimal128 differences?
(03302018 12:11 PM)Nigel (UK) Wrote: Incidentally, calculating \(\sin(\pi)\) with a 34digit value of \(\pi\), using newRPL with 34 digits of precision, gives an answer also correct to 34 digits. Well done Claudio! Thanks, but there's not much glory on that achievement. It simply uses \(\pi\) with twice the current precision, so the range reduction produces the angle with full required precision. It's easy to achieve when the whole system has variable precision. Now if you set the system to maximum precision: Code:
Now what do you see? Only 22 good digits (thanks to a few extra guard digits beyond 2000), but certainly not 2000 good digits as you would've expected. At the limit of the system precision, newRPL has the same issues of the wp34s. The only solution I found was to use 4000 digits for pi, but what's the point: if the system works with 4000 digits, then I'd rather let the user use them all, just warning them that if you use more than half of that, don't expect all corner cases to be accurate. Due to memory limitations, I chose 2000 digits as the system limit. If you use 1000 digits or less, all functions are guaranteed to give you correctly rounded results in all corner cases with the 1000 digits precision you expect. On the wp34s it's exactly the same: they used double precision to guarantee single precision on all corner cases. But since it's available, why not let the user access it? after all it's good for 99% of the cases. Now people want perfect results at double precision, so Paul needs quad precision, and then why not let the user use quad?... and here we go again. 

03302018, 04:44 PM
Post: #14




RE: WP 34S vs. DM42 decimal128 differences?
Thank you for explaining the situation in newRPL, which is an extraordinary achievement.
In the WP34S source code \(2\pi\) is already present as a constant to 450 decimal places (or thereabouts). So why not use it to get double precision answers for trig functions of double precision arguments? All it seems to take is a few code changes and one quad precision variable in one function (although whether the calculator has the RAM needed to cope with this remains an open question). I understand that in the absence of variableprecision arithmetic, chasing perfection is a way without an end. I'm also sure that Pauli has far more important things to think about. But in this case it seems that a few simple changes might make it work, and if so, why not? Nigel (UK) 

03302018, 11:26 PM
Post: #15




RE: WP 34S vs. DM42 decimal128 differences?
(03302018 04:44 PM)Nigel (UK) Wrote: \In the WP34S source code \(2\pi\) is already present as a constant to 450 decimal places (or thereabouts). So why not use it to get double precision answers for trig functions of double precision arguments? The many decimals are required to get accurate answers in single precision. E.g. try \(sin(10^{100})\). To get the same for double precision requires thousands of digits  I'd guess about 8500 give or take. Making double precision trigonometric functions accurate across their entire range isn't feasible on the hardware, there isn't enough memory. Still, you made a good argument for improving them where they are more typically used. I'll have to think it through in more detail. I'll also have to work out the worst case memory usage for functions that can call sine or cosine to see if the extra space required will fit. Were a few bytes from not fitting the stack in. Pauli 

« Next Oldest  Next Newest »

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