sin(pi) returns 0.0548, not 0: degrees, radians and calculator precedence

Last week I was checking a lab report for a friend studying engineering. He needed sin(pi), the screen showed 0.0548036651488, and the answer key said 0. He pressed it several times and concluded the thing was broken. I ran the same characters in both modes and the conclusion flipped on the spot: that number was not noise, he had fed pi in as degrees. Switch to radians and the screen gives 1.224647e-16, which is the double-precision reality of the expression that is theoretically zero. Mode, syntax and floating-point representation, all tangled in one keypress.

Split the three things apart first

Mode decides what unit the number inside the brackets is read as: in degree mode it is multiplied by pi/180 before entering the function, in radian mode it goes in unchanged. Syntax decides evaluation order: exponentiation is right-associative, factorial and percent are postfix, unary minus binds after exponentiation, all independent of units. Representation decides why the result is not exactly 0: double precision cannot hold pi, and cannot hold 0.1 either, so tails like 1.224647e-16 and 0.30000000000000004441 are inevitable.

The same expression, two columns

The table below shows the same input in both modes, raw is the double-precision value and shown is the number on screen:

cos(pi) in degree mode shows 0.998497149864: it is the cosine of an angle of 3.14159265359, which is a different question from the cosine of 180 degrees. sin(30) differs far more between the two rows, one reads it as 30 degrees, the other as 30 radians.

Syntax: three results that look like bugs

This part has nothing to do with mode, it is purely parse order. 2^3^2 shows 512: exponentiation is right-associative, the 3^2 branch is evaluated first and then 2 is raised to that, and the 64 you get by reading left to right is not what it means. 2^3! = 64, the postfix ! binds tighter than exponentiation. -2^2 = -4, unary minus comes after exponentiation, the same rule that reads -x^2 as -(x^2) in mathematics. 2+3*4 = 14 versus (2+3)*4 = 20, and sin30+1 in degree mode = 1.5, because a function without brackets consumes only the number immediately after it.

Number checklist: limits and edges

• Factorial accepts only non-negative integers, up to 170!: shown=7.257416e+306, raw=7.2574156153079940454e+306. One integer higher and the page returns no number, only a message that it is out of range; the largest double it can display is 1.797693e+308.
• The exact-integer limit is 9007199254740991, that is 2^53-1; around the 1e21 scale, 1e21+1-1e21 gives 0, the 1 you added has already been swallowed.
• Percent is a postfix operator, read as divide by 100: 200*(1+10%) shows 220 with raw 220.00000000000002842; (1+10%)^12-1 = 2.13842837672, a different route from multiplying 10% by 12.
• Thousands separators and scientific notation are both accepted: 1,000/8 = 125, 1000*(1+4.7%)^7 = 1379.19848604. The comma only groups digits, put it in the wrong place and you get an error.
• Constants and functions: pi = 3.14159265359, degrees(pi/3) = 60, log2(1024) = 10, log(8)/log(2) = 3.

Checking a whole column of intermediate values

What I had to check that day was not one problem but a whole column of intermediate values, and pressing then copying each one carries more risk of a transcription slip than of a maths error. I used the Scientific Calculator: powers, factorials, percent, modulo and implicit multiplication can be mixed, one expression per line pasted in and evaluated together; raw and displayed values come on separate lines, the mode is labelled DEG or RAD, Ans refers to the previous result, and the last 20 expressions are kept as history. Degrees and radians can be switched, division by zero, the square root of a negative number and out-of-range factorials all explain why, and expressions are evaluated locally in the browser. Evaluation runs through a hand-written lexer and a shunting-yard algorithm with no call to eval at any point, which is why I am willing to paste in someone else's whole column of expressions.

To look at a constant in another base, use the Number Base Converter; and when a problem should be done as fractions instead of staring at decimal tails first, hand it to the Fraction Calculator.

Q: When should I use DEG and when RAD?

Look at the unit of the number in the brackets. If the problem states degrees, use degree mode, sin(30) gives 0.5; if pi appears in the expression, or you are verifying an identity, switch to radians, and sin(pi) landing around 1.224647e-16 is what matches. degrees and radians ignore the switch, radians(180) is always 3.14159265359.

Q: Why is the full decimal not shown?

The display line is normalised to significant digits, 12 by default, so check the raw line for the true value. 0.1+0.2 shows 0.3 with raw 0.30000000000000004441; sqrt(2)*sqrt(8) shows 4 while the raw value is 4.0000000000000008882. That is representation error, not a wrong keypress.

Q: Why is there no result for 171!?

It falls outside what double precision can represent, so the page gives an out-of-range message instead of a number. If you need an integer ratio, cancel before the overflow: 12!/(5!*7!) = 792, 5!+3! = 126, which is safer than expanding the factorials separately.

Q: Can I assign variables and keep intermediate values?

There are no variables and no user-defined functions: letters are only accepted as registered function names and constants, anything else raises an error and points at the position. For intermediate values use Ans or MS / MR / MC. Multi-argument functions are not supported, so write a change of base as log(8)/log(2) = 3; summation and product notation are not recognised either.

Back to my friend's question about whether it was computed wrong. My order is: first check whether the mode field says DEG or RAD, which decides whether pi is read as 3.14159265359 degrees or radians; then check the syntax, because powers, factorials and unary minus are where hand calculation most often diverges; and only then look at the tail, where the digits of raw decide whether the 0.3 you see holds exactly. So sin(pi) showing 0.0548036651488 is a units problem, and showing 1.224647e-16 is a representation problem: the first only makes sense after changing mode, the second calls for a tolerance rather than expecting a 0.