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

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

I'm not sure I'd call them "problems", but it does cause
complications. There are special flags controlling conversion both
ways, including exponentialize (sin(x) => (%e^x-%e^-x)/2 ), demoivre (
%e^(%i*x) => %i sin(x) + cos(x) ), %iargs (sin(%i*x) => %i*sinh(x),
etc.  There are special simplification functions trigreduce,
trigexpand, etc. which essentially duplicate algebraic functionality
in factor, expand, etc.

But it is worth it because sin/cos are important, familiar,
real-number notations which are much more convenient than complex
exponentials in many applications.

How exactly are you going to explain to the poor user what the
difference between exp(x) and %e^x is?  Which functions (integrate,
ode, etc.) return exp and which %e^? How are you going to explain to
him that you have to call radcan (or whatever) to simplify
exp(x)-%e^x? Do you really want factor(exp(2*x)-1) to behave
differently than factor(%e^(2*x)-1)? (or add yet another obscure flag
%efactor?) Do you now introduce exp_demoivre beside demoivre?

What exactly is gained by separating exp(x) from %e^x?  So far the
only argument I have seen is that numerical evaluation doesn't do
what's expected in some cases.  I would argue that the problem is in
the numerical evaluation (numer, float, and float() in particular),
not with the %e^x notation.

> > 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.
The problem with duplication is not the effort involved in copying the
code; it is the effort involved in keeping two sets of code
synchronized.

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

Huh? Why should the user expect ev(exp(x)/x,numer) to behave any differently?

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

I agree that Maxima's inconsistency is a problem.  The solution is not
to make it more inconsistent.

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

So let's fix it.  And let's think about how numer/float really ought to behave.

           -s