error with find_root when functions containing more than one built-in constant like %pi

On 1/28/07, Stavros Macrakis <macrakis at alum.mit.edu> wrote:

> Having two distinct representations exp(x) and %e^x would
> make a mess of things.

I don't get it. There is sin(x) and (%e^(%i x) - %e^(- %i x))/(2 %i)
already, and the presence of these distinct representations doesn't
seem to cause any problems.

> And having %e^x simplify to exp(x) would mean that all
> exponentiation simplifications would have to be duplicated for exp.

I'll gladly do it myself, if it means that we can stop explaining
about %enumer.

> Fortunately, I think the problem is not so intractable. There are
> several cases which are treated specially in numeric evaluation,
> notably %e^x and x^2.  The reason for this is to avoid gratuitously
> introducing approximate numbers in contexts where no further numeric
> calculation is possible: what good does it do to have
> ev(%e^x/x,numer)=> 2.71828^x/x and ev(x^2,numer) => x^2.0?

Well, who knows. If the user writes ev(%e^x/x, numer), then it's
no longer Maxima's problem if it's not useful.

Maxima's inconsistency wrt %e (and lots of other things) is IMNSHO
its second biggest problem. (The biggest being bugs in integrate and
limit, and bugs & limitations in solve. Hmm, maybe that's three problems.)

> So... where exactly is the code that expects that
> subst(2,x,ev(%e^x,numer)) will give 7.39?  Let's just change it to
> subst(2,x,float(%e^x)) for now, and in the longer term, try to clean
> up the diverse and confusing meanings of ,numer, ,float, and float().

The code in question is in find_root -- it just needs to have
(LET (($%ENUMER T)) ...) around the evaluation of its argument ...
although in fine Maxima style that's actually (MEVAL ((MPROG) ...)).
Doubtless there are other places which need reinforcement.

All the best,
Robert