Re: Gross Bug in Simplify

*To*: mathgroup at smc.vnet.net*Subject*: [mg32656] Re: Gross Bug in Simplify*From*: Carl Woll <carlw at u.washington.edu>*Date*: Fri, 1 Feb 2002 16:11:05 -0500 (EST)*Organization*: University of Washington*References*: <a3api0$49r$1@smc.vnet.net>*Sender*: owner-wri-mathgroup at wolfram.com

Andrzej (and others interested in this thread), I won't comment on whether Alan Mason has discovered a bug, but when I looked at this problem, I discovered a different problem. Consider the following: In[419]:= Simplify[1-f[4]] Clear[f]; f[u__]^v_^:=f[u]; Simplify[1-f[4]] Clear[f] Simplify[1-f[4]] Out[419]= 1 - f[4] Out[422]= 0 Out[424]= 0 Interestingly, clearing f did not stop mathematica from thinking that 1 could be replaced by f[4]. In order to remove this definition from mathematica, one has to also clear the symbolic cache, as in In[425]:= Developer`ClearCache["Symbolic"] Simplify[1-f[4]] Out[426]= 1 - f[4] Carl Woll Physics Dept U of Washington Andrzej Kozlowski wrote: > 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. > > On Wednesday, January 30, 2002, at 05:19 PM, Alan Mason wrote: > > > There is a destructive bug in Mathematica (v4.1, win2000) in which > > Simplify > > misparses expressions m + n f[__], where m and n are numeric, as (m+n) > > f[__]. One can only wonder how many other rule combinations, with or > > without Simplify, are also faulty. > > The following example is a stripped-down version of some rules for f = > > Kronecker delta, which explains why the upvalue rule is needed. It is > > specifically this rule that seems to be causing the problem with > > Simplify. > > However, it's not the upvalue itself -- the problem remains if Power is > > Unprotected and the rule is replaced by Power[f[u__], v_] :> f[u]. > > > > In[1]:= > > Clear[f]; > > Simplify[1-f[4]] > > f[u__]^v_ ^:= f[u]; > > Simplify[{1-f[4], 1 - 7 f[4], 1 + f[4], 1 - x f[4]}] > > > > Out[2]= > > 1-f[4] > > > > Out[4]= > > {0,-6 f[4],2 f[4],1-x f[4]} > > > > Doesn't WRI test all its built-in functions by running special > > diagnostic > > code on them round the clock? It's hard to imagine how a bug like this > > could have gone undetected! > > > > Alan > > > > > > > > > Andrzej Kozlowski > Toyama International University > JAPAN > http://platon.c.u-tokyo.ac.jp/andrzej/

**Re: FindMinimum within a specific interval**

**Re: Re: Gross Bug in Simplify**

**Re: Gross Bug in Simplify**

**Re: Re: Gross Bug in Simplify**