# Why does Spotlight give a wrong value for cos(pi/2)?

As you might know, Spotlight can do simple mathematics. For instance, typing cos(pi) will result in -1, as you might expect. I just typed in cos(pi/2), which should be 0 but it gave me -5e-12.

Yes it is probably due to a rounding error, but come on: cos(pi/2)! In my opinion, that clearly looks like bug. What do you think?

-
cos(x) is a transcendental function. Unless they hardcode values for pi, pi/2, etc, you should expect some error. – Navin Mar 12 '14 at 3:38
@Navin actually I do expect them to hard-code these values since they're very important. – poitroae Mar 12 '14 at 8:35
pi itself would be hard-coded (as you get -1 for cos(pi)) but as soon as you manipulate it you get a floating point number, which has limited precision. OSX does not hard-code pi/2, pi/4 etc, it actually does the operation. – harryg Mar 12 '14 at 9:15
@harryg While there are rounding errors that can be solved by switching to decimal, this isn't one of them. Decimal is useful if you want to represent 0.1 exactly. precisely, but it's not useful for irrational numbers like pi which can't be represented exactly in either binary or decimal. – CodesInChaos Mar 12 '14 at 9:38
For reference, in Ruby: irb(main):009:0> Math.cos(Math::PI/2) => 6.123233995736766e-17 – harryg Mar 12 '14 at 10:05

It's due to the lack of precision of pi and due to the overall all lack of precision in the built-in system.

pi = 3.1415926536

pi/2 = 1.5707963268

cos(1.5707963268) = -5.103412e-12

FYI =  5.103412e-12 = 0.000000000005103412 ~ 0


About the overall system precision :

3.141592653589793238462643383 = 3.1415926536


In Python we get following :

>>> float("3.141592653589793238462643383")
3.141592653589793


As we can see there is a problem with the precision since it doesn't even match the float representation.

-
It is due to lack of precision, but an error of this magnitude cannot be blaimed on floating point numbers. – Dennis Jaheruddin Mar 12 '14 at 11:00
It probably more a lack of precision with the pi value. – Matthieu Riegler Mar 12 '14 at 11:02

It is a bug that's reproducible on 10.9.2 - and a floating point rounding error one like that is quite typical.

It's the value of pi that is being handled without enough precision if I had to guess.

• cos(999999*pi) doesn't have an error
• cos((999999+1)*pi) does have an error - likely rounding

I'd head to https://developer.apple.com/bug-reporting/ if you want to see Apple's bug fixing apparatus in action.

-
Is it a bug, really? What should be the precision on such a operation? – Édouard Mar 11 '14 at 21:56
I am not a registered developer, but I would be very grateful if you could submit it for us! – poitroae Mar 11 '14 at 22:05
@Édouard You might consider it a bug if the user has been led to expect some capability for symbolic mathematics. Any computer algebra system (CAS) will of course know that cos(π/2)=0 exactly! On the other hand, it is hardly reasonable to expect Spotlight to contain a CAS. And in the realm of floating point arithmetic, results like the OP reports are to be expected. Any bug report might be better labeled a feature request, perhaps. – Harald Hanche-Olsen Mar 11 '14 at 22:43
@Édouard bmike is in fact correct that this is a bug and not just roundoff error. The expected precision of such an operation, given standard double precision arithmetic, is about 10^-16, not 10^-12. You can try this yourself by writing a program in your favourite language that takes advantage of the CPU's floating point support, doing the calculation, and examining the bit pattern of the result. As bmike says, the likely reason is that the π value that Spotlight uses isn't defined with sufficient precision. – Szabolcs Mar 12 '14 at 2:12
Something weird is going on here. cos(2*acos(0)*0.5) returns a number of order 10^-10. So it's not because the π constant is not precise enough. I can't explain this result: it's too imprecise for double precision and too precise for single precision. – Szabolcs Mar 12 '14 at 2:37

The fact that you get a nonzero result is NOT a bug, even with a perfect implementation of the software you would run into the limits of floating point calculations. However, the error in the order of 10^-12 is really big.

This is NOT to blame to the inaccuracy of floating point numbers. The result you get is just this:

cos(1.5707963268)


That can be validated using any alternative software package. If you were to evaluate cos(pi/2) in one of those packages you will definitely get a result much closer to zero than 10^-12.

To conclude I see two possible limitations, one of which must apply:

1. Pi is not stored with sufficient precision, or at least pi/2 results in insufficient precision
2. Cos simply takes insufficient precision as input

Perhaps someone with acces to the software can validate which of these applies.

Update As mentioned in the comment the problem seems to be the accuracy of the constant pi.

-
This is weird. 1.5707963268 is the result Spotlight gives you when you compute pi/2. After a few simple tries, it seems like Spotlight displays 10 significant digits for number below 1 and 11 for numbers above 1. But for what weird implementation reason would a rounding step be applied inside the computation instead of after? – Édouard Mar 12 '14 at 10:48
I also wanted to point out that if you provide Spotlight with a more precise approximation pi/2 (by copy-pasting more than 10 digits from Wolfram Alpha, e.g.), the precision increases. – Édouard Mar 12 '14 at 11:11
@Édouard Thanks, have updated the answer – Dennis Jaheruddin Mar 12 '14 at 11:14
Thanks for confirming my guess that pi's precision was the cause of the error between 0 and roughly 10^-12 in the OP's question. – bmike Mar 12 '14 at 13:15
How often do you see this: "10^-12 is really big" – GEdgar Mar 12 '14 at 13:56

They are not storing π with unusual floating-point precision. They are using an incorrect value for π with double precision. To approximate 3.1415926536 in binary, at least 38 bits are required:

3.14159265359922… > 11.001001000011111101101010100010001001


Notice that 2^-36 is about 1.5e-11, which coincides with the trailing 99. Double-precision floating-point has a 52-bit significand. To evaluate cos(pi/2) as -5e-12, the only other possible choice would be a 48-bit type, which would be very strange.

Near 0 and π, where the derivative is nearly zero, cos(θ) cannot be calculated very accurately:

cos(3.1415926536) ≈ -0.999999999999999999999947911

That differs from -1 by about 5.2e-23, which is smaller than ε for double, so cos(3.1415926536) is calculated as exactly -1... which is incorrect.

Near ±π/2, the derivative [-sin(θ)] is nearly ±1, so the error at the input becomes the output.

cos(1.57079632679961) ≈ -4.71338076867830836e-12
cos(1.57079632679962) ≈ -4.72338076867830836e-12
cos(1.57079632680000) ≈ -5.10338076867830836e-12


I happen to have a TI calculator that displays one less digit and calculates cos(π/2) as -5.2e-12. However, it is very different electronically and was designed to give an exact value for cos(90°).

I would guess that in Spotlight, cos(pi/2) is being calculated by retrieving a value for π, converting to a decimal string, storing that as the (exact, rational) binary value 11.00100100001111110110101010001000100100001101101111 (or 10000), dividing by 2, and then essentially subtracting that from the true value of π/2. You should find out whether cos(pi/2 + cos(pi/2)) is closer to zero (it might be -2.2e-35).

Multiplication by a power of two should affect only the exponent, not the significand. It might be possible to determine how rounding is applied by repeated halving or doubling.

-
Nothing is wrong with the Markdown — MathJax is only enabled on Math-related sites, not SE-wide. – grgarside Mar 12 '14 at 20:06
cos(pi/2 + cos(pi/2)) displays as 0 exactly. – kundor Mar 13 '14 at 0:07

Considering that -5e-12 is a verryyyy small number, this is a rounding error.

I think it's the consequence of spotlight showing more decimals than than are used in the definition of the pi constant or the infinite series used to calculate trig functions.

-