Subject: [ maxima-Bugs-609464 ] 1+%e,numer and %e^%e,numer
From: Stavros Macrakis
Date: Wed, 13 May 2009 23:12:24 -0400
I am having some trouble getting to the Sourceforge page on bug 609464
"1+%e,numer and %e^%e,numer", which I originally opened 7 years ago
(!), but I think it's worthwhile discussing your recent contribution
on the mailing list.
The initial comment was:
> %e^%e,numer does not evaluate numerically to 15.15...
> as it should, it simply returns the simplified expression
> %e^%e.
Your recent note on the bug page talks about numer and %enumer, but I
think it is worthwhile to review the original rationale for numer,
%enumer, etc.
The idea of 'numer' is to convert to floating-point any non-trivial
numeric subexpressions (including symbolic constants such as %pi and
%gamma) of a symbolic expression while preserving its symbolic
structure. It explicitly *avoids* converting to floating-point the
trivial subexpressions which are already integers, notably exponents
(x^3) and bases of powers (2^x), in order to preserve the form of the
expression and ensure that later simplifications (based on whatever
the value of x is) are as accurate as possible -- you don't really
want to factor(x^2.0-1.0).
If %e^x,numer became 2.718^x, then substituting x->log(y) would result
in 2.718^log(y), which Maxima can't simplify in any useful way (though
it arguably should simplify it to %e^(1.0*log(y)).
My original bug note did *not* question this behavior. It only
pointed out that in some cases where a non-trivial subexpression could
be evaluated numerically, it was not.
-s