sin(x)^2+cos(x)^2 = 1 on different calcs

[tcab]

I’ve just been playing around with truism that sin(x)^2+cos(x)^2 = 1.

I ran a loop checking this for different values of x on different calcs, incl Python. Let’s say x ranges from 0..20.

I expected the result to be 1 in all cases but of course such is the nature of floating point that some results are 1 or 0.999999999999 or 1.0000000000000002 thus disappointingly, not exactly 1 in all cases.

The interesting thing is that Python, Prime and Free42 give different results, and the ‘errors’ occur at different points, presumably due to the different math/floating point engines. The only calc that had no errors was Free42, which gave 1 in all cases.

Hp Prime

Code:


SINCOS(X)
BEGIN
  RETURN SIN(X)^2+COS(X)^2;
END;

EXPORT SINCOSLOOP()
BEGIN
LOCAL I;
FOR I FROM 0 TO 20 DO
  PRINT(I + " " + SINCOS(I));
END;
END;

Gives 1 for all values except 1, 6, 7, 9 where it gives 0.999999999999 as the answer.

Python

Code:


import math
def sincos(x):
    res = math.sin(x)**2 + math.cos(x)**2
    return res
    
for i in range(20):
    print(i, sincos(i))

Gives:

Code:


0 1.0
1 1.0
2 1.0
3 0.9999999999999999
4 1.0
5 0.9999999999999999
6 0.9999999999999999
7 0.9999999999999999
8 1.0
9 0.9999999999999999
10 1.0
11 1.0
12 1.0
13 1.0
14 1.0
15 1.0
16 1.0
17 0.9999999999999999
18 1.0
19 0.9999999999999999

Reassuringly, Free42 gives 1 in all cases. I used my python to rpn converter https://pyrpn.herokuapp.com to create the Free42 program, since I already had the Python code worked out. I just had to move the for loop before the sincos function, and change math.sin to SIN.

Code:


LBL("sincosloop")
for i in range(20):
    print(i, sincos(i))
def sincos(x):
    res = SIN(x)**2 + COS(x)**2
    return res

which converted into the HP 42S RPN of

Code:


01 LBL "sincosl"
02 -1.19
03 STO 00
04 LBL 00
05 ISG 00
06 GTO 01
07 GTO 02
08 LBL 01
09 CLA
10 RCL 00
11 IP
12 ARCL ST X
13 ├" "
14 RCL 00
15 IP
16 XEQ A
17 ARCL ST X
18 AVIEW
19 GTO 00
20 LBL 02
21 RTN
22 LBL A
23 STO 01
24 RDN
25 RCL 01
26 SIN
28 X↑2
29 RCL 01
30 COS
32 X↑2
33 +
34 STO 02
35 RCL 02
36 RTN

which when run, shows 1 in all cases, and if virtual printing is on with PON you get to see the list of values on the virtual printer tape, confirming this.

An interesting evening’s research :-)

[Joe Horn]

(09-24-2018 02:05 PM)tcab Wrote:  I’ve just been playing around with truism that sin(x)^2+cos(x)^2 = 1.

I ran a loop checking this for different values of x on different calcs, incl Python. Let’s say x ranges from 0..20.

The only calc that had no errors was Free42, which gave 1 in all cases.

Not really; it just LOOKS like 1. Output sin(x)^2+cos(x)^2-1 instead, and you'll see where it wasn't really 1, as well as the size of the error (which is extremely small). It also depends on which angle mode you're in.

[BartDB]

Hi,

You understand the limits of floating point, but dissapointed that it's not 1 in all cases?

Now you may say "but Free42 always gets 1"

You don't state which version of Free42 you're using. Probably "Decimal", in which case it is quadruple precision decimal floating-point which gives 34 decimal digits of precision. Also, it keeps all 34 digits with each calculation to reduce rounding error. So for the 12 displayed digits, there are 22 further digits not displayed.

Try the following:
COS(2*PI/3) + 0.5

On the Decimal version you'll get 3E-34

Now for interest, subtract 1 from each result in your previous experiment.
.

[pier4r]

a search with the search string : site:www.hpmuseum.org accuracy OR precision on your favorite search engine returns a lot of useful discussion since the accuracy topic is one of the most discussed (and less understood) that I can remember.

[Albert Chan]

(09-24-2018 05:16 PM)Joe Horn Wrote:  Not really; it just LOOKS like 1. Output sin(x)^2+cos(x)^2-1 instead, and you'll see where it wasn't really 1, as well as the size of the error (which is extremely small). It also depends on which angle mode you're in.

Agreed. The "1" may be just a rounded number.
However, subtract 1 to peek at the errors might not work.
Some (most?) calculator, trying to be "nice", will convert the tiny amount to zero.

http://people.ku.edu/~wzhuang/CAMseminar...ecrets.pdf

Better approach is get around the trigger, and subtract, say 0.999999999

[Dieter]

(09-24-2018 02:05 PM)tcab Wrote:  I’ve just been playing around with truism that sin(x)^2+cos(x)^2 = 1.

I ran a loop checking this for different values of x on different calcs, incl Python. Let’s say x ranges from 0..20.

I expected the result to be 1 in all cases but of course such is the nature of floating point that some results are 1 or 0.999999999999 or 1.0000000000000002 thus disappointingly, not exactly 1 in all cases.

There is nothing to be disappointed about. On the contrary, you should be glad that the result is not (!) 1 in all cases.

Consider the case sin(6°) and cos(6°).

sin(6°) = 0,104528463267653...
cos(6°) = 0,994521895368273...

Any decent 12-digit calculator should return 0,104528463268 and 0,994521895368. The square of the sine is not much of a problem here. But since the cosine is rounded down, its square is also slightly below the true value, and here it shows in the 12 digit:

0,994521895368^2 = 0,989073800366359... or 0,989073800366 (rounded to 12 digits)
while the true value is
0,994521895368273...^2 = 0,989073800366902... or 0,989073800367 with 12-digit precision.

So there are cases where the errors due to rounding to a given number of places compensate each other, while in others they add up and so they show up in the result. It simply depends on how the first discarded digit rounds. Both in the sine and cosine as well as in their squares.

If a calculator actually returned 1 exactly in all cases I'd be concerned about its accuracy. ;-)

Dieter

[Gerald H]

HP 30S returns exactly 1 for input

sin(.1)^2+cos(.1)^2

[Joe Horn]

(09-25-2018 04:22 AM)Gerald H Wrote:  HP 30S returns exactly 1 for input

sin(.1)^2+cos(.1)^2

Indeed, sin(x)^2+cos(x)^2-1 returns 0 for every x I've tried. However:

(09-24-2018 07:09 PM)Dieter Wrote:  If a calculator actually returned 1 exactly in all cases [for sin(x)^2+cos(x)^2] I'd be concerned about its accuracy. ;-)

Dieter is right. Besides, the 30S isn't really an HP calculator. It's a rebranded knockoff of somebody else's calculator. Proof: do 1/3, then Ans×3, then Ans-1. It returns zero, which proves it's cheating by fudging results.

[Albert Chan]

(09-25-2018 05:19 AM)Joe Horn Wrote:  Dieter is right. Besides, the 30S isn't really an HP calculator. It's a rebranded knockoff of somebody else's calculator.
Proof: do 1/3, then Ans×3, then Ans-1. It returns zero, which proves it's cheating by fudging results.

Agreed. Many (most?) calculators cheat, to give "nice" answer.
They call this "small differences set to zero feature" ... I hate it

I am not sure about the proof though. IIRC, 30S use binary mathematics:

1/3 = 0.010101011 (binary, say 8 bits mantissa)
2/3 = 0.10101011
3/3 = 1.000000001 -> half-way round-to-even = 1.0

1/3 = 0.01010101 (binary, say 7 bits mantissa)
2/3 = 0.1010101
3/3 = 0.11111111 -> half-way round-to-even = 1.0

So, whatever bits 30S uses (odd or even), 1/3*3 = 1, no cheating (in this case)

[J-F Garnier]

(09-25-2018 02:35 PM)Albert Chan Wrote:  I am not sure about the proof though. IIRC, 30S use binary mathematics:

1/3 = 0.010101011 (binary, say 8 bits mantissa)
2/3 = 0.10101011
3/3 = 1.000000001 -> half-way round-to-even = 1.0

1/3 = 0.01010101 (binary, say 7 bits mantissa)
2/3 = 0.1010101
3/3 = 0.11111111 -> half-way round-to-even = 1.0

So, whatever bits 30S uses (odd or even), 1/3*3 = 1, no cheating (in this case)

Yes, the 1/3*3-1 test doesn't work on binary machines.
In this case, I'm using the test 1/3+1-1-1/3 to estimate the mantissa resolution (number of bits).

BTW, The MS excel is using the "small differences set to zero feature" , but you can defeat it easily by using parentheses:
e.g. =1/3+1-1-1/3 -> 0
but =(1/3+1-1-1/3) -> -5.55112E-17 (2^-54)

J-F
[edited: corrected 2^-54]

[Joe Horn]

Thanks, Albert and J-F,! I didn't know that fact about binary machines. Makes perfect sense. Awesome!

[cyrille de brébisson]

Hello,

In excel
=100-99.99-0.01 -> 5.1157E-15
shows that it does not "move small differences to 0....

However, I have NO clue what might be going on with
=1/3+1-1-1/3 and =(1/3+1-1-1/3)

This is a very interesting case! and I really would like to know what is happening behind the scenes!

Cyrille

[Werner]

Cyrille:
Same for =1-0.99-0.01 vs. =(1-0.99-0.01)
It shows Excel does cheat, but that can never be done consistently.
They should've adopted decimal floating point a long time ago.
Cheers, Werner

[J-F Garnier]

(09-26-2018 05:27 AM)cyrille de brébisson Wrote:  However, I have NO clue what might be going on with
=1/3+1-1-1/3 and =(1/3+1-1-1/3)
This is a very interesting case! and I really would like to know what is happening behind the scenes!

1/3 = 0.0101010101... (binary)
1/3+1 = 1.01010101... (shift the mantissa right by 2 bits, loosing one bit at the mantissa end)
1/3+1-1 = 0.01010101... ( one bit is 0 at mantissa end)
so the final difference 1/3+1-1-1/3 is one bit.

Quote:=100-99.99-0.01 -> 5.1157E-15
shows that it does not "move small differences to 0....

This case is more complex, because 99.99 and 0.01 doesn't have simple binary representations. The difference 5.1157E-15 has a mantissa with several bits set (more than two).

(09-26-2018 06:37 AM)Werner Wrote:  Cyrille:
Same for =1-0.99-0.01 vs. =(1-0.99-0.01)
It shows Excel does cheat, but that can never be done consistently.
They should've adopted decimal floating point a long time ago.

=(1-0.99-0.01) -> 8.67362E-18 = 2^-57+2^-59
Maybe excel is cheating when the mantissa has up to 2 bits close to the end.

And I'm happy that excel is using binary arithmetic, I never encountered such situations in real life but had to deal with very large and complex spreadsheets to do system simulations, and speed was the main point.

J-F

[Thomas Okken]

(09-26-2018 07:37 AM)J-F Garnier Wrote:  And I'm happy that excel is using binary arithmetic, I never encountered such situations in real life but had to deal with very large and complex spreadsheets to do system simulations, and speed was the main point.

...but when calculating with money, decimal fractions really should be exact, and spreadsheets are very commonly used for calculations involving money (which, presumably, is why Excel tries to cheat).

[Werner]

(09-26-2018 09:58 AM)Thomas Okken Wrote:  ...but when calculating with money, decimal fractions really should be exact, and spreadsheets are very commonly used for calculations involving money (which, presumably, is why Excel tries to cheat).

My reasoning exactly, Thomas.

Cheers, Werner

[Albert Chan]

(09-26-2018 05:27 AM)cyrille de brébisson Wrote:  =100-99.99-0.01 -> 5.1157E-15
shows that it does not "move small differences to 0....

The difference is not small, if think in ULPs (above case, 1 ULP = 2^-59):

100 - float(99.99) = 0x147ae147ae2000 ULP
float(0.01) = 0x147ae147ae147b ULP

Difference = 0x2000 - 0x147b = 2949 ULP

Quote:However, I have NO clue what might be going on with
=1/3+1-1-1/3 and =(1/3+1-1-1/3)

I am using *old* MS Excel 95.
It does not have set-to-zero "feature".
So, both expressions return the same -5.6E-17

[Csaba Tizedes]

I dunno how its relevant: on my CASIO fx-991ES SUM(SIN(X)^2+COS(X)^2-1,0,90) gives 0, SUM(SIN(X)^2+COS(X)^2,0,90)-91 also 0, SUM(SIN(X)^2,0,90)+SUM(COS(X)^2,0,90)-91 same (0). After then I used integration and the result is also zero! Wow! My CASIO is perfect.

[Albert Chan]

Hi, Csaba Tizedes

You got a big 0 for sums because of another Casio "feature".
For example, below test from my Casio-FX115MS, which claimed 12 internal digits.

9999999999 ->M (M has full 10 digits)

M + 0.94 - M ==> 0.94
M + 0.95 - M ==> 1 ???

M + 0.10 - M ==> 0.10
M + 0.09 - M ==> 0 ???

So, sin(X)^2 + cos(X)^2 get rounded to exactly 1 (Almost always)
This, on top of small difference set-to-zero "feature"

Edit: round-up feature only for M with all 9s. Do not know why ...

[Csaba Tizedes]

(09-27-2018 03:34 PM)Albert Chan Wrote:  You got a big 0 for sums because of another Casio "feature".

No, this is alien technology!



Cs.