MathGroup Archive 2002

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

Search the Archive

Re: Gross Bug in Simplify

  • To: mathgroup at smc.vnet.net
  • Subject: [mg32607] Re: Gross Bug in Simplify
  • From: <emueller at ybkim.mps.ohio-state.edu>
  • Date: Thu, 31 Jan 2002 01:45:35 -0500 (EST)
  • Organization: Ohio State University
  • References: <a38b1s$1r$1@smc.vnet.net>
  • Sender: owner-wri-mathgroup at wolfram.com

With your rule for f, f raised to the zeroth power equals f.  Simplify is
just using this fact to put the expression in its simplest form.

What you probably want is something like

f[u__]^v_?(#!=0&) ^:= f[u]

Erich

(ie. the observed behavior was not a bug)

On Wed, 30 Jan 2002, 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
> 
> 
> 
> 



  • Prev by Date: Re: Keeping order with Union
  • Next by Date: RE: Keeping order with Union
  • Previous by thread: Gross Bug in Simplify
  • Next by thread: Re: Gross Bug in Simplify