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).

The answer is still the same as it was here. The prior post in that thread has examples that show different behavior.

– Daniel Lichtblau – 2013-12-21T20:47:25.413Ah, someone's here from Wolfram. That's good. I would assert that this behavior of

`/`

in a numerical expression is abug.`/`

should always give the most accurate result on machine numbers, but it currently does not. As it stands, I now have to use`Divide`

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. – Mark Adler – 2013-12-21T21:16:01.617And yes, I will also submit a bug report in the official manner. – Mark Adler – 2013-12-21T21:19:43.147

8I made inquiries about the feasibility of changing the evaluation parsing/semantics of '/' to be like Divide. I was informed that this was considered some time ago, and rejected, because it would be backwardly incompatible for situations where HoldXXX are in play. I guess more generally it would create trouble if '/' was not an infix surrogate for '

' (with inversion of the right hand argument). Reason being, a chain like `ab/cde/f*g`would no longer parse to something with head of`

Times` and seven arguments. – Daniel Lichtblau – 2013-12-22T23:03:45.1775The classic "too hard to fix" response to a bug. C'mon, you guys are smart. Suppose you retained information about the split of the original divide operation so that the multiplication and reciprocal could be recombined into a division when the time came to actually do the operation? – Mark Adler – 2013-12-23T01:14:52.587

Or, you could defer the split of

`Divide[]`

until a symbolic operation comes into play. – Mark Adler – 2013-12-23T20:34:48.647