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

> > (2) Maxima simplifies exp(x) to %e^x and the special cases for %e
> > are probably related to that. As an alternative Maxima could refrain
> > from exp(x) --> %e^x, and then treat %e like other constants.

An important technique in Maxima simplification is to reduce as many
things as possible (or convenient) to quasi-canonical forms involving
a very small number of basic operations.  Thus 1/x => x^-1, abs(x^3)
=> abs(x)^3, etc., though on the other hand cos(x) /=> sin(x+pi/2)
(read /=> as "does not simplify to"), sinh(x) /=> (%e^x+%e^-x)/2, etc.

Having two distinct representations exp(x) and %e^x would make a mess
of things. And having %e^x simplify to exp(x) would mean that all
exponentiation simplifications would have to be duplicated for exp.

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? ... as
opposed to %e^2.3 => 9.97 and 4.5^2 => 20.25, where an exact quantity
is being combined with an approximate one.

Apparently there are some places in the Maxima system (or in user
code?) where it is being assumed that ev(%e^x,numer) will become
2.718^x.  And why?  Perhaps because they want the "float" property to
be attached to the expression somehow.  But that doesn't work in other
cases.  What should ev(x,numer) or ev(x/(x+y),numer) become? There is
no way of marking the result of those expressions as requiring
floating calculation: x*1.0 or x+0.0, which are candidates, will
immediately simplify back to x.

Now it turns out that Maxima (as I've pointed out before) is not
really consistent here.  It would be logical to carry along the
symbolic expressions x+0.0 and x*1.0, as a way of expressing that the
final calculation is limited to floating precision (Maxima generally
avoids converting approximate numbers to exact ones, and when it does,
it warns you: cf. rat(x+2.3) ).  Maxima also simplifies x^1.0 => x.
Peculiarly, it does not simplify x^-1.0 to 1/x, though (1/x)^1.0 does
simplify to 1/x -- I guess this is just a bug....

Or perhaps the problem is that people are using ev(...,numer) or
ev(...,float) where they should be using float(...).  It's certainly
true that this situation is confusing and messy, and we should fix it,
but let's not throw the baby out with the bathwater by making exp(x)
the standard representation for %e^x.

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().

             -s