[Date Index]
[Thread Index]
[Author Index]
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]]
>
>
>
>
>
Prev by Date:
**Re: Gross Bug in Simplify**
Next by Date:
**Re: How to draw such 3D surface?**
Previous by thread:
**Re: Gross Bug in Simplify**
Next by thread:
**Re: Simulating Correlated non-Normal Random Variables**
| |