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 > > > >