Different trig algorithms in CAS and Home?

[TheKaneB]

Hi,

I couldn't find this while searching through the forum, if it has been already discussed I'm sorry for the double post.

Anyway, if I do the following function in CAS and in Home I get 2 different answers (radians mode):

Home:
TAN(355/226) = −7497089.06508

CAS:
approx(TAN(355/226)) = −7497258.47868

The CAS result is more accurate than the Home result. Anybody knows the reason why they differ? Also, is the CAS trig implementation really different or is it a quirk of the approx() function?

For reference, WolframAlpha says that the answer is -7.4972581853255871129050718318912486634172679437852631..... 10^6

The CAS version got 7 digits correct, while the Home version only calculated 4 correct digits. (I am assuming that all the digits from WolframAlpha are correct, which I think is what all of us will expect).

[salvomic]

(01-03-2018 08:17 PM)TheKaneB Wrote:  ...
CAS:
approx(TAN(355/226)) = −7497258.47868

...

Besides: 355/226 is 1.57079646018;
CAS:
TAN(1.57079646018) returns -7497089.14193, another approximation...

Definitely curious...

[TheKaneB]

Oh, thanks Salvo for adding that

[salvomic]

(01-03-2018 08:49 PM)TheKaneB Wrote:  Oh, thanks Salvo for adding that

you're welcome!

Sure parisse will be so kind to tell us something about that apparently strange difference.

However, 1.57079 rad is about 90°, so a tangent must return actually infinity and we could consider the "n*1E6 about" number almost equal to infinity...

Salvo

[TheKaneB]

Uhm... I can't reproduce your result, maybe you copy pasted the displayed result of the fraction? That way probably you've lost a few extra hidden digits in the intermediate result.

   

[salvomic]

(01-03-2018 10:00 PM)TheKaneB Wrote:  Uhm... I can't reproduce your result, maybe you copy pasted the displayed result of the fraction? That way probably you've lost a few extra hidden digits in the intermediate result.

Antonio, in Home execute 355/226, then press TAN(), highlight the above result of the fraction, tap and pass it to TAN(), then execute it.

[TheKaneB]

yes, that procedure I think loses a few hidden digits. That's my speculation though, correct me if I am wrong!

[salvomic]

(01-03-2018 10:11 PM)TheKaneB Wrote:  yes, that procedure I think loses a few hidden digits. That's my speculation though, correct me if I am wrong!

yes, maybe...
However, consider what I said above: 1.5 rad is too close to 90°, so every "big number" is "about ∞", and every approximation is not much significant...

Salvo

[TheKaneB]

Oh yes, that's done on purpose! I was playing around with these "torture tests" http://www.voidware.com/calcs/torture_trigs.htm

The experiment I did was to show 2 different results from the same calculator to the same expression. I don't care if I have even 3 or 4 correct digits in such corner cases. For practical purposes that is a singularity point

[salvomic]

(01-03-2018 10:18 PM)TheKaneB Wrote:  Oh yes, that's done on purpose! I was playing around with these "torture tests" http://www.voidware.com/calcs/torture_trigs.htm

The experiment I did was to show 2 different results from the same calculator to the same expression. I don't care if I have even 3 or 4 correct digits in such corner cases. For practical purposes that is a singularity point

ok,
then:
Free42: -7497258.18533
HP-15C and HP-41CX -7507225.705 (not -7.518796992e6 as we read in that site), both the same number
HP 50g: -7497089.06508 (like the Prime in Home)
old CASIO PB-110 (1983): -7497938.067
TI Voyage 200: -7497257.878
old TI 74: -7497263.499
...
:-)

For Italian speakers: "numeri del Lotto", random (approximation) numbers, hi.

[TheKaneB]

HP 30B same result as the 50G and Prime Home

About the 15C, they report exactly your result (4th row), take a second look, it looks like you read the 3rd row by mistake, the one with the HP 65 result

[Joe Horn]

(01-03-2018 08:17 PM)TheKaneB Wrote:  Hi,

I couldn't find this while searching through the forum, if it has been already discussed I'm sorry for the double post.

Anyway, if I do the following function in CAS and in Home I get 2 different answers (radians mode):

Home:
TAN(355/226) = −7497089.06508

CAS:
approx(TAN(355/226)) = −7497258.47868

The CAS result is more accurate than the Home result. Anybody knows the reason why they differ?

Believe it or not, BOTH of Prime's results are as accurate as possible... IF you keep in mind how Prime rounds its internal floating point numbers in Home and in CAS (they're different).

Home uses 12-digit BCD floating-point reals. So 355/226 is internally represented as EXACTLY 1.57079646018 followed by an infinite number of zeros. PLEASE NOTE that this is NOT mathematically equal to 355/226. It's rounded off to 12 significant digits, as necessarily must happen in Home. Now if you use a high-precision calculator (e.g. HP 50g with LongFloat set to 100 digits of accuracy) you'll see that TAN(1.57079646018) is -7497089.06507601... which, when rounded to the mandatory 12 significant digits, is −7497089.06508 which is exactly what you saw TAN(355/226) return in Home. So it's the best possible answer that a 12-digit BCD calculator can get.

CAS uses 48-bit binary floating-point reals. So 355/226 is internally represented as EXACTLY 221069948522749/2^47. As above, please note that this is not mathematically equal to 355/226; it's the largest 48-bit number which does not exceed 355/226, which is the best that CAS can do. Now if you use a high-precision calculator (e.g. HP 50g with LongFloat set to 100 digits of accuracy) you'll see that TAN(221069948522749/2^47) is -7497258.47868147... which, when rounded to the Prime's maximum display of 12 significant digits, is −7497258.47868 which is exactly what you saw TAN(355/226) return in CAS. So it's the best possible answer that a 48-bit binary calculator can get.

[TheKaneB]

Thank you Joe! Being a programmer, that's exactly the kind of answer I was hoping for!

[salvomic]

(01-04-2018 01:52 AM)Joe Horn Wrote:  Believe it or not, BOTH of Prime's results are as accurate as possible... IF you keep in mind how Prime rounds its internal floating point numbers in Home and in CAS (they're different).
...
So it's the best possible answer that a 12-digit BCD calculator can get.
...
So it's the best possible answer that a 48-bit binary calculator can get.

Thank you Joe, as always a precise and informative explanation!

Salvo

[chromos]

BTW is there reason for such 'low' 12 digit precision in HP Prime? Even my very old TI-58C with 4kHz CPU and 480 bytes RAM computes to 13 digits.

[Dieter]

(01-04-2018 08:23 AM)chromos Wrote:  BTW is there reason for such 'low' 12 digit precision in HP Prime? Even my very old TI-58C with 4kHz CPU and 480 bytes RAM computes to 13 digits.

The TI58 and 59 work with 13-digit precision, but this does not mean you get 13-digit accuracy. Try sin(45°), cos(45°) and sqrt(0,5). Even in simple calculations the last digit usually is truncated instead of correctly rounded: try 2/3, which yields 0,6666666666666 instead of ...67.

The Prime (like other 12-digit HP calculators) internally works with 15 (!) digits. The result is finally rounded to 12 digits and then displayed. This way the returned value usually is exact in all digits. OK, even this way there are cases where the last digit may be slightly off. Avoiding this would require an even higher internal precision.

Dieter

[chromos]

(01-04-2018 08:46 AM)Dieter Wrote:  The Prime (like other 12-digit HP calculators) internally works with 15 (!) digits.
Dieter

Thank you for reply, Dieter, even it didn't answer my question why current calculator doesn't have better precision (or accuracy - my knowledge of english isn't capable differentiate these terms) than calculator 40 years old.

How do you know the HP Prime works with 15 digits internally? There is only one information about Prime precision in user manual (both Quick Start Guide and User Guide Phase 2):

• On the other hand, non-CAS calculations, such as those performed in HOME view or by an app, are numerical calculations and are often approximations limited by the precision of the calculator (to 12 significant digits in the case of the HP Prime).
  

And if I try:

• 1/9-.111111111111 // i.e 12 times number '1'
  

then I get 0 instead of 1.11e-13.

[Dieter]

(01-04-2018 02:39 PM)chromos Wrote:  Thank you for reply, Dieter, even it didn't answer my question why current calculator doesn't have better precision (or accuracy - my knowledge of english isn't capable differentiate these terms) than calculator 40 years old.

I think there is an answer. ;-) The question is whether the TIs have an advantage or not. This requires some insights on how TI and HP calculators work.

Since about 1976 HP's calculators internally work with (usually) three so-called guard digits, i.e. they carry out their calculations with 3 more digits than returned to the user. So the HP67 or HP41 display 10 digits, but they use 13 internally. This is required to ensure full 10-digit accuracy for the final result, and in most cases this goal is met. So once the calculation is done, the result is rounded to 10 digits, and this rounded result is displayed.

The TIs follow a different approach. The TI58/59 also use 13 digits for their calculations, just as the HPs do. But they do not round their results before they are returned to the user: instead they give you all 13 digits. Which means that the last one or two may be off.

Example: try 3^4 on the TI58/59. The 10-digit display will show "81" - fine. But the result actually is 80,99999999996. The HPs probably have not got a better result with their internal 13-digit calculation, but they round it off to 81 (10 digits) before it is shown to the user. These are simply two different philosophies: both TI and HP used 13 digits for their computations. While TI chose to return all 13 - knowing that the last one or two may be off - the HP approach was to play safe and return only what (most probably) was exact.

Both philosophies have their benefits. I like the idea of having 13 digits not only internally, but for all user calculations. Even if the result is not dead on (it can be rounded to display precision with a EE INV EE sequence). On the other hand I also appreciate the HP way of returning only reliable 10 digits.

This also explains your observation that 1/9 - 0,111111111111 yields zero. Of course it does: the returned 12-digit value of 1/9 is 0,111111111111, so the difference is indeed zero. Remember that the 15 digits are only used internally and not exposed to the user.

(01-04-2018 02:39 PM)chromos Wrote:  How do you know the HP Prime works with 15 digits internally?

Well, all HP calculators with 12-digit BCD arithmetics I know of use 15 digits internally, just as the 10-digit devices use 13. So I think it's safe to assume that the Prime doesn't behave differently here. ;-)

But you can do a test: Try sin(3,14159265359) in radians mode. The TI58/59 returns a plain zero here. The common 12-digit HPs give the correct result -2,06761537357 E-13. Which shows that pi internally is stored with much higher precision than 12, 15 or even 20 digits.

Dieter

[Didier Lachieze]

(01-04-2018 06:46 PM)Dieter Wrote:  

(01-04-2018 02:39 PM)chromos Wrote:  How do you know the HP Prime works with 15 digits internally?

Well, all HP calculators with 12-digit BCD arithmetics I know of use 15 digits internally, just as the 10-digit devices use 13. So I think it's safe to assume that the Prime doesn't behave differently here. ;-)

As explained here the HP 48 math library (Saturn assembler) has been rewritten In C to be used in the new HP calculators starting with the HP 20b/30b. This explains why the results of the HP Prime in Home mode are the same as the HP 48.

[chromos]

(01-04-2018 06:46 PM)Dieter Wrote:  

(01-04-2018 02:39 PM)chromos Wrote:  Thank you for reply, Dieter, even it didn't answer my question why current calculator doesn't have better precision (or accuracy - my knowledge of english isn't capable differentiate these terms) than calculator 40 years old.

I think there is an answer. ;-)

...
...

Dieter

No, it's still not answering my question why current calculator (HP Prime) with 32bit ARM9 CPU @400MHz has +/- the same number of significant digits as calculator 40 years old (TI-58/59) with 4bit TMC0501 @200kHz. Maybe my question is badly formulated? Nevertheless thank you for your time you put into your reply.

(01-04-2018 07:49 PM)Didier Lachieze Wrote:  As explained here the HP 48 math library (Saturn assembler) has been rewritten In C to be used in the new HP calculators starting with the HP 20b/30b. This explains why the results of the HP Prime in Home mode are the same as the HP 48.

Thank you, Didier, now I got it.