# Why to do parentheses change the results of a calculation?

I'm getting results that are sensitive to where I place parentheses with respect to operations that are associative1 (and should thus be insensitive to such placement). For example, if I define2

<< Units; << PhysicalConstants;
stellarDayTextbook = 1/(1/Day + 1/Convert[SiderealYear, Day])


and then calculate

1/stellarDayTextbook - 1/Day - 1/Convert[SiderealYear, Day]


I get precisely zero, as expected. But if I add parentheses

(1/stellarDayTextbook - 1/Day) - 1/Convert[SiderealYear, Day]


I get

-(3.03577*10^-17/Day)


What's causing this?

1. Remember, this isn't C, it's math: "subtraction" of $x$ is just the addition of $-x$. Check TreeForm.

2. I realize this isn't the definition of a "stellar day", but merely a textbook approximation. The distinction is not material to the question.

• Subtraction is associative? en.wikipedia.org/wiki/Associative_property Nov 13, 2012 at 16:01
• @alancalvitti: Ok, ok: go ahead and replace all the - with +-. Nov 13, 2012 at 16:05
• Just numerical roundoff error here. We know the order of evaluation for the parenthesized version, and clearly the order is different for the unparenthesized version. Use Chop on the result to get rid of the error. Nov 13, 2012 at 16:07
• In any case, floating point operations are not necessarily associative/distributive, even if the underlying mathematical operations are.
– rm -rf
Nov 13, 2012 at 16:26
• Actually just like in C, addition of floating point (inexact) numbers isn't associative in Mathematica either ... Nov 13, 2012 at 18:53

What you're seeing here is just the impreciseness of floating point arithmetic. It is important to remember that floating point operations are not associative or distributive even if the underlying mathematical operations are. A very simple example demonstrating the lack of associativity:

1. + (1.*^20 - 1.*^20)
(* 1. *)

(1. + 1.*^20) - 1.*^20
(* 0. *)


Much has been said and written about this topic over the years, so instead of repeating, I'll just link you to a good article to read on the subject: D. Goldberg, "What every computer scientist should know about floating-point arithmetic," ACM Comput. Surv. 23, 1 (March 1991), 5-48

• As discussed in the comments above, it's interesting that Mathematica does not take advantage of its knowledge of expression structure to produce a more accurate result. Jan 12, 2014 at 2:30
• @raxacoricofallapatorius its does If one uses exact numbers. (1 + 1*^20) - 1*^20 gives 1 Jan 12, 2014 at 2:34
• @Nasser: But only because those calculations are exact, not because Mathematica is removing the parentheses symbolically. Jan 12, 2014 at 2:53
• @raxacoricofallapatorius Mathematica is not magic. It neither knows what you intended to achieve nor can it feasibly infer that from some kind of analysis of the sum total of all system, package, and user code that it processes. Anyway, this got my upvote for an excellent reference. Jan 12, 2014 at 2:59
• @raxacoricofallapatorius not necessarily, when you are working with floating point values. Mathematica is essentially stuck between those who want floating point numbers to behave as an exact analogy to the reals, and those who insist that they are legitimate mathematical objects in their own right, with their own special rules of algebra. I think the compromises that have been made to accommodate both of these classes of users are mostly reasonable, but there are obviously limits to what can be done. The important point is to be aware of what you are really doing so as not to be surprised. Jan 12, 2014 at 4:01