39
$\begingroup$

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.

Improve this question
$\endgroup$
6
  • $\begingroup$ The answer is still the same as it was here. The prior post in that thread has examples that show different behavior. $\endgroup$ – Daniel Lichtblau Dec 21 '13 at 20:47
  • $\begingroup$ 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. $\endgroup$ – Mark Adler Dec 21 '13 at 21:16
  • $\begingroup$ And yes, I will also submit a bug report in the official manner. $\endgroup$ – Mark Adler Dec 21 '13 at 21:19
  • 8
    $\begingroup$ I 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 a*b/c*d*e/f*g would no longer parse to something with head of Times and seven arguments. $\endgroup$ – Daniel Lichtblau Dec 22 '13 at 23:03
  • 5
    $\begingroup$ The 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? $\endgroup$ – Mark Adler Dec 23 '13 at 1:14
38
$\begingroup$

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

Improve this answer
$\endgroup$
8
  • 7
    $\begingroup$ Sure enough. Divide[15, 137.] - 15/137. gives 1.38778*10^-17. Fascinating. $\endgroup$ – Mark Adler Dec 21 '13 at 3:10
  • 2
    $\begingroup$ @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. $\endgroup$ – Szabolcs Dec 21 '13 at 3:22
  • 7
    $\begingroup$ The 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. $\endgroup$ – Mark Adler Dec 21 '13 at 3:31
  • 3
    $\begingroup$ @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]]. $\endgroup$ – Szabolcs Dec 21 '13 at 3:55
  • 1
    $\begingroup$ 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. $\endgroup$ – Silvia Dec 21 '13 at 3:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.