[Date Index]
[Thread Index]
[Author Index]
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/
Prev by Date:
**Re: FindMinimum within a specific interval**
Next by Date:
**Re: Re: Gross Bug in Simplify**
Previous by thread:
**Re: Gross Bug in Simplify**
Next by thread:
**Re: Re: Gross Bug in Simplify**
| |