Re: arcsin(arccos(arctan(tan(cos(sin(9))))))




Phil Carmody wrote:

Guy Macon <http://www.guymacon.com/> writes:

The more I think about this, the odder it seems.
Consider A, B, and C below:

A 3.141592653589793238462643383279502884197169399375105820974944592...
B 3.141592653589793238462643383279502884197169399311481966593000574
C 0.000000000000000000000000000000000000000000000063623854381944018

A is the value of Pi up to the 64th digit.

B is what the calculator that comes with Microsoft Windows displays
(in 64-digit mode) when you click on the "Pi" button, which I jokingly
call "Microsoft Visual Pi++." Only the first 47 digits are correct.

47 digits just under 2^160. Maybe they use 5 limb bignums?
However, the value printed isn't a whole multiple of 2^-160,
so that's not necessarily the case at all.

C is the (tiny) difference between the two.

I would understand if Microsoft only used the first 32 digits,
or perhaps a few more as guard digits, but I can't understand
why they would use a *wrong* value. Simple carelessness?
Anyone using the calculator in its default 32-digit mode
wouldn't see any difference except in very rare circumstances,
but still, it would have been just as easy to do it right.
Could it be that Microsoft runs some srt of buggy Pi generator
rather than simply storing the value of Pi internally? Weird.

Calculating it definitely could explain it. What does it
think atan(1)*4 is to that precision?

atan(1)*4 =
180.0000000000000000000000000000000000000000000055654005077611413

Interesting! the string of zeros stops at digit 48 -- the same
digit where Pi started being wrong.

--
Guy Macon
<http://www.guymacon.com/>


.

Quantcast