Re: Inconsistencies and special treatment of %e vs. %pi (and numer, %enumer mess)

No, I don't want to kill simpexpt. :)
As I said, I was referring to the function simplifya, which is the
top-level simplification function. It currently is responsible for
converting %e to 2.718..., while the conversion of other constants like %pi
to their numeric value is handled by the evaluator.
This is inconsistent, surprising to developers (probably causing bugs when
they think that atoms are always simplified and don't need to go through
the simplifier) and causes all kind of strange behavior.

Am Mi., 10. Juni 2026 um 15:49 Uhr schrieb Michel Talon <
[email protected]>:

>
> Le 09/06/2026 à 12:05, David Scherfgen via Maxima-discuss a écrit :
>
>
>    - There's one way it could work, although it comes with a catch:
>
>
>    - We stop handling %e in simplifya entirely. *Nice side effect: Atoms
>    are always simplified!*
>
> Do you mean you want to kill simpexpt in simp.lisp? It contains stuff that
> is really simplification and not evaluation, for example the action of
> function %especial (in csimp.lisp) which simplifies exp(p/q*%i*%pi+x) when
> q = 2, 3, 4, or 6. For example
>
> %e^(%i*%pi/4+x) -> (1+%i)/sqrt(2)*%e^x
>
> and many other simplifications, which are true whether or not the x above
> is symbolic or numeric. In this respect %e cannot be treated like %pi, i
> think. When numer is true, i think the result should be completely numeric.
>
>
>
> --
> Michel Talon
>
> _______________________________________________
> Maxima-discuss mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>

_______________________________________________
Maxima-discuss mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/maxima-discuss