Why do different calculators disagree on $\cos(452175521116192774 )$

calculatormachine precisiontrigonometry

I want to calculate cosine of 452175521116192774 radians (it is around $4.52\cdot10^{17}$)
Here is what different calculators say:

Wolframalpha WolframAlpha

Desmos

Desmos

Geogebra

Geogebra

Python 3.9 (standard math module)

Python

Python 3.9 (mpmath library)

Python3

Obviously there is only one solution. There could be errors in floating point precision for these calculators, but this stumbles me. My calculator (TI-30XIS) says domain error (which is weird because cosine of, for example, a billion works just fine). How can I get the cosine of very large integers?

Best Answer

The problem is that your integer $$n=452175521116192774$$ can't be stored exactly as a standard 64-bit IEEE double precision floating point number. The closest double happens to be $$x=452175521116192768,$$ as can be seen from the binary representation $$ \begin{aligned} n &= 11001000110011100110011110110100000010000100000000000\color{red}{000110}_2 \\ x &= 11001000110011100110011110110100000010000100000000000\color{red}{000000}_2 \end{aligned} $$ where those last few bits in $n$ are lost, since the double format only stores the first 52 digits after the leading “1”.

So in systems that use standard floating point (like Desmos, Geogebra, and the Python math module) you will actually get $x$ when you enter $n$ in a place where a double is expected; in Python you can verify this as follows:

> print("%.310g" % 452175521116192774)
452175521116192768

Conseqently, when you ask for $\cos n$ these systems will answer with $$\cos x = -0.2639 \ldots$$ (which in itself is computed correctly; it's just that the input is not what you thought).

In contrast, Wolfram Alpha and mpmath work with the exact number $n$, and give the correct answer $$\cos n = -0.5229 \ldots$$

Related Question