Robert Israel wrote: > Axel Vogt <&noreply@axelvogt.de> writes: > >> Walter Roberson wrote: >> ... >> > The above are simple cases of obvious defects, unless you are >> willing to >> > define away a complete session crash as not being a "defect". >> Vladimir's >> > tools are more refined, finding situations where products produce >> > dubious or decidedly incorrect answers. I don't think it would have >> taken >> > very long to find such a case in Matlab 2008b: all one would have to do >> > is pull out some of the cases one had recorded against Maple, transpose >> > them into Matlab notation, and watch as the Maple-based Matlab >> Symbolic >> > Toolbox >> > reproduced the existing Maple bug. For example, Maple 12: >> > >> >> log(exp(RootOf(_Z*exp(_Z)))); simplify(%); >> > Error, (in ln) numeric exception: division by zero >> > >> > but evalf(RootOf(_Z*exp(_Z))) is 0, and log(exp(0)) is 0 so there >> should >> > be no division by zero. >> ... >> >> This Maple bug steps in before log, already at >> 'simplify( exp(RootOf(exp(_Z))) )'. > > That is a different bug, I think. Zeros of exp(_Z) do not exist, but Maple > does not know that, so it essentially applies the simplification rule > f(RootOf(f(_Z))) = 0. > > I think what you mean is > > simplify(exp(RootOf(_Z*exp(_Z)))); > > or more generally > > simplify(f(RootOf(f(_Z)*g(_Z)))); > > 0 > > If w is a zero of f(_Z)*g(_Z), we must have f(w) = 0 or g(w) = 0. I don't > know why Maple jumps to the conclusion that f(w) = 0 here.
Thx, f(RootOf(f(_Z))) = 0 sounds like a reason to me.
I have the errors for 'exp(RootOf(exp(f(T)))); simplify(%);' as well and dito with a factor exp(RootOf(f*exp(_Z))) or for f a function
