MathGroup Archive 2002

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

Search the Archive

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