4

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.
J. M.'s missing motivation
  • 124,525
  • 11
  • 401
  • 574
DonComo
  • 43
  • 1
  • 3
  • 5
    Sin[2] is an exact expression, as simple as possible. 0.909297 is a numerical approximation. Both representations are useful in different contexts. – bill s Feb 16 '14 at 16:55
  • 8
    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. – Szabolcs Feb 16 '14 at 17:04
  • 1
    It's good to note that you'll find the same behaviour with virtually all computer algebra systems. – Szabolcs Feb 16 '14 at 17:06
  • Also explained here but not sure if this constitutes a duplicate. – bobthechemist Feb 16 '14 at 18:06
  • 4
    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. – Oleksandr R. Feb 16 '14 at 20:12

1 Answers1

4

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.

PlaysDice
  • 804
  • 6
  • 11
  • 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. – DonComo Feb 16 '14 at 21:13
  • 1
    @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. – Oleksandr R. Feb 16 '14 at 21:41
  • 1
    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 :) – carlosayam Feb 16 '14 at 22:18
  • @caya My hunch is that, even though you use N[] on separate terms, Mathematica evaluates the expression without N[] and than uses N[] on the resulting expression. But this is just speculation, I currently have only a limited understanding of the language. – DonComo Feb 16 '14 at 22:46
  • @DonComo based on this you can make your own function Clear[newsine];newsine[x_]:=Sin[Rationalize[x]] and call it using newsine[1.23] etc – PlaysDice Feb 16 '14 at 23:14
  • 2
    @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. – Szabolcs Feb 16 '14 at 23:15
  • @Szabolcs Did you find a precision for which the equality does not hold? I've tried this Manipulate[ N[Sin[2], prec]^2 + N[Cos[2], prec]^2 == 1, {prec, 2, 10, 1}] and it shows True every time... – DonComo Feb 16 '14 at 23:20
  • @DonComo We're getting pretty deep into how precision works in Mathematica, and I don't think the comments are a good place to discuss this. There are other reasons too why it gives True, e.g. the fact that == has a tolerance for MachinePrecision numbers. But generally: if you use MachinePrecision, the calculations are fast, but they're done at a fixed precision and there's no precision tracking. So often you'll get a very small number where you'd expect zero (e.g. substituting the solution into an equation and evaluating numerically). You can join the chat for details. – Szabolcs Feb 16 '14 at 23:25
  • @Szabolcs Edit: I understand now what happens, I've just tested with Trace and you are right. Sorry, it's late on my side :) Thanx – DonComo Feb 16 '14 at 23:26
  • 2
    @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. – Oleksandr R. Feb 16 '14 at 23:27