Services & Resources / Wolfram Forums
-----
 /
MathGroup Archive
2002
*January
*February
*March
*April
*May
*June
*July
*August
*September
*October
*November
*December
*Archive Index
*Ask about this page
*Print this page
*Give us feedback
*Sign up for the Wolfram Insider

MathGroup Archive 2002

[Date Index] [Thread Index] [Author Index]

Search the Archive

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