Re: Just another Mathematica "Gotcha"
- To: mathgroup at smc.vnet.net
- Subject: [mg120795] Re: Just another Mathematica "Gotcha"
- From: Daniel Lichtblau <danl at wolfram.com>
- Date: Wed, 10 Aug 2011 06:47:33 -0400 (EDT)
- Delivered-to: l-mathgroup@mail-archive0.wolfram.com
----- Original Message -----
> From: "AES" <siegman at stanford.edu>
> To: mathgroup at smc.vnet.net
> Sent: Tuesday, August 9, 2011 6:19:34 AM
> Subject: Just another Mathematica "Gotcha"
> Seems as if the following two expression should yield the same output
> -- seems that way to me anyway -- but they don't. I'll hide the
> actual outputs down below so Mathematica gurus (or "ordinary users")
> can make their predictions as to which one does what.
>
> In[1]:= Series[a+(b1+b2)x,{x,0,1}] //Normal /.{b2->0}
>
> In[2]:= Series[a+(b1+b2)x,{x,0,1}] /.{b2->0} //Normal
>
> My conclusions:
>
> 1) By any normal rules of interpretation or ordinary interpretations
> of these statements, they both should do the same same thing.
>
> 2) This is just another Mathematica "Gotcha" -- and not a
> particularly forgivable one.
Bunk.
You forgot an important third variant.
Series[a + (b1 + b2) x, {x, 0, 1}] /. {b2 -> 0} // Normal
I think you will expect it to give a + b1*x. Which it does. There is an important point to be made about this, to wit...
> Out[1]= a+(b1+b2) x
>
> Out[2]= a+b1 x
... this third variant and your first cannot possibly have the same behavior in general. For a fundamental reason, having essentially nothing to do with Mathematica per se. It is this. One of the infix // or /. must have higher precedence than the other. So either the Normal will not be applied (because it would bind to {b2->0}) or the replacement would not (because it parsed as (Normal/.{b2->0}) which simply evaluates to Normal).
So which of the following would you like to see?
(1) No infix \\ ?
(2) No infix \. ?
(3) Swapping the precedence of those two infix operators (and perhaps getting a surprise from my third variant)?
(1) and (2) of course will not happen. My suspicion is that the precedence is best left as is because people usually expect \\ to bind fairly loosely. At present, /. is almost as loose so the change would not be tremendous. But still that would be a change that would almost certainly break some amount of existing code. Might fix some as well, but I won't go into that other than to say that people should understand operator precedence if they intend to use it in a nontrivial manner.
Possibly you have other alternatives to propose.
Daniel Lichtblau
Wolfram Research