Open pane opened 1 month ago
Oh, that's interesting. This would only apply to DEG and GRAD - in RAD mode, I assume that anything I might do would be worse than the built-in IEEE floating-point math. Now that I have add/subtract/multiply/divide in decimal internally, using that to normalize the angle into the unit circle is reasonably straightforward.
I wouldn't expect it to give identical results for really big numbers, like say 721e25, since my internal decimal routines aren't exactly the same as the 15C's. The internal decimal stuff I wrote is a place where I just used brute force, to take the place of the many man-years HP spent optimizing highly efficient code. Since I have multiple orders of magnitude more compute power, I just do internal multiplications to 22 decimal digits of mantissa, because the only thing that cost me was typing in "22" instead of "14" or "12" or whatever the optimal answer would have been. So anyway, if I internally normalize an angle like 721e25 degrees to the unit circle, I'll almost certainly get a different answer than a real 15C. But for something within the range of the available decimal precision, like 720e8 or 721e8, I should get the same answer.
Actually, I was able to get good results even for silly angles, like 7.21e99 degrees. If you take the value 7.21e99 as being exact, it's possible to modulo it by 360 exactly, by successively subtracting multiples of 360 that stay within the available precision. When I do that, I get exactly the same result as my 15C.
BTW, it turns out that 7.21e99 modulo 360 is 280.
Actually, I was able to get good results even for silly angles, like 7.21e99 degrees. If you take the value 7.21e99 as being exact, it's possible to modulo it by 360 exactly, by successively subtracting multiples of 360 that stay within the available precision. When I do that, I get exactly the same result as my 15C.
Nice (brute) touch, thank you for investing your man-years in JRPN.
KR P
Hi Bill,
Reading through "The New Accuracy: Making 2^3=8" (HP Journal, October 1976, pages 16-17) HP took extra afford to make improvement while prescaling argument for trigonometric functions in the user's units first until unit circle is reached and only after that converted argument to radians for calculation. I assume this is not implemented in JRPN (2.1.16) this way.
Please see: HP 15 CE tan (720E08) = 0 JRPN 15 C (2.1.16) tan (720E08) = 0,000000082
Additional context Not a big deal, just an observation and not important for the use, but surprisingly HP made an effort to polish this edge use.
Side note: As indicated in #87 I would find more useful if there is an option/switch to select between either "Dart RND" or HP RND" generator sequence since you can verify the code correctness when using particular seed - this could be helpful in some instances to keep this fidelity with the real15C.
As always, thank you for your afford and constant improvements.
KR P