## Is there a difference between Divide[a,b] and a/b?

39

8

In this comment it was asserted that Divide[a,b] and a/b are different, though the documentation indicates that they are the same. In particular, it was asserted that a/b is evaluated as a * 1/b, whereas Divide[a,b] performs the division directly. It was further asserted that this could result in an observable difference in behavior for machine-precision numbers.

The question is: is there a difference? If so, what is it exactly? How does it manifest itself? Is there an example where Divide gives a different result than /?

I tried a few edge cases with $MaxMachineNumber and $MinMachineNumber, but didn't find any differences in behavior between the two.

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

Ah, someone's here from Wolfram. That's good. I would assert that this behavior of / 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 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.617

And 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*gwould no longer parse to something with head ofTimes and seven arguments. – Daniel Lichtblau – 2013-12-22T23:03:45.177

5The 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

38

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:=
On[]
Divide[4,8]
Off[]

During evaluation of In:= On::trace: On[] --> Null. >>
During evaluation of In:= Divide::trace: 4/8 --> 1/2. >>

Out= 1/2

In:=
On[]
4/8
Off[]

During evaluation of In:= On::trace: On[] --> Null. >>
During evaluation of In:= Power::trace: 1/8 --> 1/8. >>
During evaluation of In:= Times::trace: 4/8 --> 4/8. >>
During evaluation of In:= Times::trace: 4/8 --> 1/2. >>

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

7Sure enough. Divide[15, 137.] - 15/137. gives 1.38778*10^-17. Fascinating. – Mark Adler – 2013-12-21T03:10:34.400

By camparing with N[15/137, 100], 15/137. looks preciser. Does a/b always preciser than Divide[a, b] for machine-precision a and b? – Silvia – 2013-12-21T03:15:55.350

2@Silvia If you compare the binary digits directly, using RealDigits[..., 2], you'll see that all binary digits of Divide[15,137.] are correct, but the last two binary digits of 15/137. are wrong. Generally the Divide form is more likely to be correct because it is a result of a single division. The / form is the result of two operations: a division and a multiplication, so roundoff errors may accumulate. – Szabolcs – 2013-12-21T03:22:14.587

7The documentation (which we have already established as incorrect) indicates that $a\div b$ (a[esc]div[esc]b) is another way to write Divide[a,b]. However it is actually interpreted as a/b. I think that documentation needs some work. – Mark Adler – 2013-12-21T03:31:58.997

3@MarkAdler Some more observations: HoldComplete[Divide[a,b]] prints as HoldComplete[$\frac{a}{b}$], but it does actually keep the internal representation as Divide (as shown by FullForm). However, typing HoldComplete[Divide[a,b]] and then pressing Command-Shift-N to convert to StandardForm destroys Divide, and replaces it with /. Evaluating it and using FullForm gives Times[a,Power[b,-1]]. – Szabolcs – 2013-12-21T03:55:39.663

1

Hmm.. That is different from my observation.. I compared all Divide[k, n] vs k/n for k and n both from 1 to 200. Looks like the chance is 50-50.

– Silvia – 2013-12-21T03:58:24.067

1FWIW, here is my code: res=Table[MapThread[#1@#2&,{{(len=Length[#];#)&[RealDigits[#,2][]]&,RealDigits[#,2][]&,RealDigits[#,2][[1,1;;len]]&},{Divide[k,SetPrecision[n,MachinePrecision]],k/SetPrecision[n,MachinePrecision],N[k/n,100]}}]//Length/@{LongestCommonSubsequence[#[],#[]],LongestCommonSubsequence[#[],#[]]}&//#1-#2&@@#&,{n,1,200},{k,1,200}] – Silvia – 2013-12-21T04:11:26.497

Any theories about why Mathematica automatically goes the weird way? – Rojo – 2013-12-22T04:35:06.777