Oleksandr is correct about the way evaluation works. a/b
seems to be interpreted (parsed) directly as Times[a, Power[b,-1]]
, or more readably: $a\times b^{-1}$. Divide[a,b]
is interpreted as is. Evaluation then proceeds from these forms, and the arithmetic is carried out differently for the two cases: either $a\times (1/b)$ or $a/b$.
Here are some examples that illustrate the evaluation sequence:
In[95]:=
On[]
Divide[4,8]
Off[]
During evaluation of In[95]:= On::trace: On[] --> Null. >>
During evaluation of In[95]:= Divide::trace: 4/8 --> 1/2. >>
Out[96]= 1/2
In[98]:=
On[]
4/8
Off[]
During evaluation of In[98]:= On::trace: On[] --> Null. >>
During evaluation of In[98]:= Power::trace: 1/8 --> 1/8. >>
During evaluation of In[98]:= Times::trace: 4/8 --> 4/8. >>
During evaluation of In[98]:= Times::trace: 4/8 --> 1/2. >>
Out[99]= 1/2
This can indeed theoretically lead to different machine precision results. Let's find out if it really does! We are going to compare the complete binary representation of the results, and we won't use ==
or ===
(which both have some tolerance).
Table[{k, RealDigits[k/137., 2] === RealDigits[Divide[k, 137.], 2]}, {k, 1, 20}]
(* ==> {{1, True}, {2, True}, {3, True}, {4, True}, {5, True}, {6, True}, {7, True},
{8, True}, {9, True}, {10, True}, {11, True}, {12, True}, {13, True},
{14, True}, {15, False}, {16, True}, {17, True}, {18, True}, {19, True}, {20, True}}
*)
So Divide[15, 137.]
and 15/137.
really do lead to different results. Conclusion: yes, there is an observable difference.
Again, keep in mind that even ===
has some tolerance (Internal`$SameQTolerance
) when comparing machine precision numbers (though less than ==
, Internal`$EqualTolerance
) and 15/137. === Divide[15, 137.]
returns True
. The difference is there though as evidenced by the full 53-bit binary representation.
So will you ever see the effects of this in practice? Theoretically the error may accumulate, and there are some functions which do not honour these tolerances and perform strict comparisons (try e.g. Union[{15/137., Divide[15, 137.]}]
, which returns a list of length 2).
/
in a numerical expression is a bug./
should always give the most accurate result on machine numbers, but it currently does not. As it stands, I now have to useDivide
wherever/
used to be in order to get the correct result. That is a giant pain, since I suddenly lose 800 years of development of a convenient mathematical notation. $\endgroup$ – Mark Adler Dec 21 '13 at 21:16a*b/c*d*e/f*g
would no longer parse to something with head ofTimes
and seven arguments. $\endgroup$ – Daniel Lichtblau Dec 22 '13 at 23:03