# Why does Mathematica evaluate Sin[2.0] but not Sin[2]? [closed]

I can't understand why is it that

In[88]:= Sin[2]
Out[88]= Sin[2]


while

In[89]:= Sin[2.0]
Out[89]= 0.909297


I even tried

In[90]:= 2 + Sin[2]
Out[90]= 2 + Sin[2]


thinking that it might force the evaluation, but apparently not...

Now, I know that I can just do this

In[91]:= N[Sin[2]]
Out[91]= 0.909297


but I am curious why doesn't just Sin[2] work.

Even though the Documentation Center page for Sin[x] contains Possible Issues examples this behavior is not mentioned.

I know from some experience with Python and C that expressing a integer number, e.g. 2, as a rational number, i.e. 2.0, can influence the way an expression is evaluated, e.g.

#Python code
>>> 5 / 2
2
>>> 5 / 2.0
2.5


Even though I personally don't agree with this behavior (I think there should be different operators for integer division and rational division since it will always cause some confusion) if you just see some examples it becomes clear what happens.

Here I don't have any idea what Mathematica thinks when it sees Sin[2]

Note:

• I'm using Mathematica v7.0
• I'm basically a beginner.
• I don't plan and have time to go through a tutorial, I just wanted to play around. I expected the simple/common things to behave intuitively enough.
• I also appreciate if you point me to some resources where this behavior is explained.
• Sin[2] is an exact expression, as simple as possible. 0.909297 is a numerical approximation. Both representations are useful in different contexts. Commented Feb 16, 2014 at 16:55
• The difference between exact and approximate numbers in Mathematica is explained here. Sin[2] simply cannot be represented in decimal notation. It can only be approximated with a finite number of digits. If you give exact input to Mathematica (integers are considered exact) then it will give you an exact output, the simplest form of which here is Sin[2]. Sin[Pi] would give an exact 0, Sin[Pi/3] would give Sqrt[3]/2, but you can't reduce Sin[2] further without using approximations. Commented Feb 16, 2014 at 17:04
• It's good to note that you'll find the same behaviour with virtually all computer algebra systems. Commented Feb 16, 2014 at 17:06
• Also explained here but not sure if this constitutes a duplicate. Commented Feb 16, 2014 at 18:06
• I think you got your answer already. But just to anticipate future questions: note that, in Mathematica, numbers expressed as decimals are not considered to be rationals, but rather reals with some associated uncertainty. This is very unusual and can lead to confusion for those used to other languages. Commented Feb 16, 2014 at 20:12

The Mathematica tutorial on Numerical Precision

gives a brief intro of how Mathematica handles certain numerical inputs. Under Documentation, Details for Sin guides that "certain special arguments" are automatically evaluated to exact values. But in your examples, Mathematica sees the input value of 2. as a machine precision number and, per the Documentation "Machine-Precision Numbers", you will get a machine precision output. Otherwise, per the other answers & comments, Mathematica maintains your exact input in an exact form unless you apply numerical evaluation (e.g N@Sin[2]).
Try these:

Plot[Sin[x],{x,0,2}]
Table[Sin[x], {x, 0, 2, 0.1}]


Note the machine precision value for step-size (0.1). Mathematica returns machine-precision results even with the first value, x=0 (!)

Table[Sin[x],{x,0,2,1}]


...uses exact values all the way down.

Also compare:

Sin[2]*Pi
N@Sin[2]*Pi
Sin[2]*Pi // N
N[Sin[2]*Pi]


The last 3 give the same numerical value, using alternate syntax. The function N can also be used with a second value to provide n-digits of precision e.g N[Sin[2]*Pi,10] gives 10 digit precision. See Documents for N.

• Thanks for the answer. Given that Sin[2] is evaluated to the exact value but for a number like 1.23 Sin[1.23] evaluates to a machine precision number the following question may arise: How do I evaluate Sin[1.23] to exact value? It occurred to me that in this case I could use Sin[123/100]. This could be extended to other decimal numbers. Commented Feb 16, 2014 at 21:13
• @DonComo yes, that's right. You can either use Rationalize to whatever tolerance you think appropriate, or SetPrecision[..., Infinity] if you want to treat the floating point number like the rational that it really is. Commented Feb 16, 2014 at 21:41
• Funnily enough, @DonComo, this N[Sin[2], 2]^2 + N[Cos[2], 2]^2 == 1 is True, although you may get a very different result in traditional programming languages. Here is what you get in Ruby (irb):  Math.sin(2).round(2)**2 + Math.cos(2).round(2)**2 == 1 => false. The reason is that Mathematica keeps track of precision and, at the level of precision requested, the two expressions are the same :) Commented Feb 16, 2014 at 22:18
• @DonComo The two N are evaluated separately, as you can verify with Trace. The reason why it gives true is what caya said. Mathematica keeps track of precision and up to 2 digits the equality holds. Commented Feb 16, 2014 at 23:15
• @DonComo Equal has a tolerance of 7 bits for machine precision or higher; SameQ has a tolerance of 1 bit. caya's example basically asks if 1.1.7 == 1.16. or not. The answer is clearly yes, regardless of the tolerance. But this tolerance is another thing to watch out for as it is not just unexpected for most people but also poorly documented. Commented Feb 16, 2014 at 23:27