Re: Re: Gross Bug in Simplify

*To*: mathgroup at smc.vnet.net*Subject*: [mg32647] Re: [mg32643] Re: Gross Bug in Simplify*From*: Andrzej Kozlowski <andrzej at platon.c.u-tokyo.ac.jp>*Date*: Fri, 1 Feb 2002 16:10:46 -0500 (EST)*Sender*: owner-wri-mathgroup at wolfram.com

Well, as I and a few others pointed out, what you have observed not only is not a "gross bug" but it is not any bug at all. In fact I was rather impressed with Simplify for getting this right. > It seems counterintuitive to have to add the condition, even granting > that > Mathematica always treats f^0 as 1, even for symbols f. On the contrary, it is as intuitive as could possibly be since it follows from primary school math. And yes, f^0 is 1 not just for symbols: In[1]:= "I think you just covering up your own blunder"^0 Out[1]= 1 > Also, the > phenomenon in question occurs only with Simplify-- not with other > functions > such as Expand, e.g. This is no argument at all since anyone with even a little acquaintance with Mathematica would notice that Simplify and FullSimplify are unlike all other functions including Expand etc. After all: In[8]:= Expand[3+x>1+x] Out[8]= 3+x>1+x In[9]:= Simplify[3+x>1+x] Out[9]= True and so on... As for your last example, quite frankly I think it you really should know better. If anything that example is a bug, though certainly not a "gross" one. The actual transformations used by Simplify and the order in which they are applied are difficult to predict and all kind of things can effect them, including even the names of the symbols (as was illustrated by a recent example in this list). So the fact that in some particular case some transformation is not used is certainly not an argument for the view that in an another cases, when it was used, it was the result of a bug. In fact in your case all you need to do is to change the formula very slightly to again see the same thing happen (quite correctly!): In[1]:= (Clear[\[Delta]]; ); (SetAttributes[\[Delta], Orderless]; ); (\[Delta][u__]^v_ ^:= \[Delta][u]; ) In[2]:= Simplify[(2*x - x*\[Delta][i, \[Mu]])*\[Delta][j, \[Mu]]] Out[2]= x*\[Delta][i, \[Mu]]*\[Delta][j, \[Mu]] Regards Andrzej Kozlowski Toyama International University JAPAN http://platon.c.u-tokyo.ac.jp/andrzej/ On Friday, February 1, 2002, at 04:03 PM, Alan Mason wrote: > > "Andrzej Kozlowski" <andrzej at platon.c.u-tokyo.ac.jp> wrote in message > news:a3api0$49r$1 at smc.vnet.net... >> I can't see why you claim this is a bug and that it is caused by >> >>> Simplify misparses expressions m + n f[__], where m and n are >>> numeric, as (m+n) >>> f[__] >> >> It seems to me that what you are seeing is just a special case of the >> following: >> >> In[1]:= >> z/:z^v_=z; >> >> >> >> In[2]:= >> Simplify[1-z] >> >> Out[2]= >> 0 >> >> This seems to me entirely correct, since z==1 is the only complex >> number >> with the property that z^(anything)==z. Thus it would appear that your >> function f[z__] ought to have the value 1 for all arguments. This is >> consistent with all your outputs. Maybe I am missing your point, but >> mathematically at least there appears to be nothing wrong here. >> > Hello. > > To be sure, I can get things to work by adding a condition to the rule: > > In[33]:= > \[Delta][u__]^v_ ^:= \[Delta][u] /; v \[NotEqual] 0 ; > Simplify[(1-\[Delta][i,\[Mu]]) \[Delta][j,\[Mu]]] > > Out[34]= > -(-1+\[Delta][i,\[Mu]]) \[Delta][j,\[Mu]] > > > It seems counterintuitive to have to add the condition, even granting > that > Mathematica always treats f^0 as 1, even for symbols f. > But your logic doesn't explain why my original rule (without the > condition) > gives > > In[51]:= > Clear[\[Delta]] > SetAttributes[\[Delta], Orderless]; > \[Delta][u__]^v_ ^:= \[Delta][u] ; > Simplify[(2- x \[Delta][i,\[Mu]]) \[Delta][j,\[Mu]]] > > Out[54]= > (2-x \[Delta][i,\[Mu]]) \[Delta][j,\[Mu]] > > Clearly in this case, Mathematica isn't treating delta[__] as 1. Also, > the > phenomenon in question occurs only with Simplify-- not with other > functions > such as Expand, e.g. > > Perhaps someone can account for the behavior illustrated in the > following > notebook; I am unable to do so. I continue to think it's a "gross bug" > in > Simplify. > > :=)) > > Sincerely, Alan > > In[1]:= > Clear[\[Delta]] > SetAttributes[\[Delta], Orderless]; > \[Delta][u__]^v_ ^:= \[Delta][u] ; > Simplify[(2 - \[Delta][i,\[Mu]]) \[Delta][j,\[Mu]]] > Simplify[(2- x \[Delta][i,\[Mu]]) \[Delta][j,\[Mu]]] > Expand[(2- \[Delta][i,\[Mu]]) \[Delta][j,\[Mu]]] > > Out[4]= > \[Delta][i,\[Mu]] \[Delta][j,\[Mu]] > > Out[5]= > (2-x \[Delta][i,\[Mu]]) \[Delta][j,\[Mu]] > > Out[6]= > 2 \[Delta][j,\[Mu]]-\[Delta][i,\[Mu]] \[Delta][j,\[Mu]] > > In[7]:= > Clear[\[Delta]]; > \[Delta][u__]^v_ ^:= \[Delta][u] /; v \[NotEqual] 0; > Simplify[(2-\[Delta][i,\[Mu]]) \[Delta][j,\[Mu]]] > > > Out[9]= > -(-2+\[Delta][i,\[Mu]]) \[Delta][j,\[Mu]] > > > > >

**Re: Gross Bug in Simplify**

**Re: How to draw such 3D surface?**

**Re: Gross Bug in Simplify**

**Re: Simulating Correlated non-Normal Random Variables**