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

--===============6567737254904579071==
Content-Type: multipart/alternative; boundary="0000000000000fe1d20654da6707"

--0000000000000fe1d20654da6707
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Part of the current special treatment of %e was introduced for the sole
purpose of making %enumer "work", i.e. being able to convert a standalone
%e to a float, but not an %e in %e^(...) - which isn't a bad idea, in my
opinion.

Unfortunately, it doesn't work, as I showed in my initial message. And, in
fact, it's very difficult if not impossible to make it work in the
simplifier, because it sometimes operates top-down and sometimes bottom-up.
When working bottom-up, the simplifier first sees only the %e, and it would
have to make a decision right at that moment whether to convert it to a
float or not. However, it doesn't know if the %e is a standalone %e or an
%e^(...). It cannot know.

If this conditional conversion of %e to a float were to be done in the
evaluator instead of in the simplifier, it could be done reliably, since
the evaluator works top-down. It first sees the %e^(...) before seeing the
%e alone, therefore it can make the proper decision.

In conclusion, I see 3 ways forward:
1) Leave %enumer broken.
2) Degrade %enumer: make it a selective switch for either converting all or
no instance of %e to a float when numer is true (breaking compatibility).
3) Remove all special treatment of %e from the simplifier and let the
evaluator do it properly. This would be more consistent with how other
constants are treated, but it also may break some existing code that relies
on this special, partly broken, behavior.

Richard Fateman <[email protected]> schrieb am Mo., 22. Juni 2026, 18:25:

> I agree with Stavros on this.
> Note that ((mexp) 1) would be a clumsy way of representing what is now
> %e...
>
>
> On Mon, Jun 22, 2026 at 9:09=E2=80=AFAM Stavros Macrakis <macrakis@gmail.=
com>
> wrote:
>
>> On Mon, Jun 22, 2026 at 2:42=E2=80=AFAM Robert Dodier <robert.dodier@gma=
il.com>
>> wrote:
>>
>>> On Wed, Jun 10, 2026 at 6:56=E2=80=AFAM David Scherfgen via Maxima-disc=
uss
>>> <[email protected]> wrote:
>>> ...Stepping back a bit, I believe it would be better overall to
>>> represent
>>> the exponential function as something like ((MEXP) ...) instead of
>>> ((MEXPT) $%E ...) mostly because the former is more fundamental...
>>
>>
>> That is not a good idea. One of the basic Maxima conventions is to
>> minimize duplication in representations; and Don't Repeat Yourself
>> <https://en.wikipedia.org/wiki/Don%27t_repeat_yourself> is just standard
>> good software engineering practice. So for example, Maxima treats *a-b* =
as
>> *a+(-1)*b* rather than having a special subtraction operator.
>> Representing *%e^x *as *exp(x)* would mean that all the simplification
>> logic for exponentials would have to be duplicated so that e.g. *exp(x)*=
exp(y)
>> =3D> exp(x+y)*. It would mean adding an additional clause to pretty much
>> every function that dispatches on operator e.g. a separate clause for *d=
iff(exp(x),...)
>> *vs. *diff(2^x,...)*. Presumably *simpexpt* would canonicalize *%e^x *to
>> *exp(x)*, so at least *%e^x-**exp(x) *would simplify to zero. I'm not
>> concerned about the effort to do this, nor even the risk of missing case=
s
>> or introducing new bugs -- I'm concerned that every time one piece of
>> functionality is expressed in two different ways, it bloats the code bas=
e
>> and makes it harder to understand and to maintain.
>>
>> True, there are cases where we have redundant functions. We could
>> canonicalize *gamma(x) *to *(x-1)! *or vice versa; and *sin(x) *to
>> *cos(x-%pi/2)*, etc. Or, to take the notion of using the "most
>> fundamental" representation to its logical conclusion, simply represent
>> trig/hyperbolic functions with *exp* (i.e. *exponentialize* them all). A=
ctually,
>> I *do* think that it would be a good idea for *gamma/!* (with them being
>> treated as selectable presentation options), but that's another discussi=
on.
>> _______________________________________________
>> 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
>

--0000000000000fe1d20654da6707
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">Part of the current special treatment of %e was introduce=
d for the sole purpose of making %enumer &quot;work&quot;, i.e. being able =
to convert a standalone %e to a float, but not an %e in %e^(...) - which is=
n&#39;t a bad idea, in my opinion.<div dir=3D"auto"><br><div dir=3D"auto">U=
nfortunately, it doesn&#39;t work, as I showed in my initial message. And, =
in fact, it&#39;s very difficult if not impossible to make it work in the s=
implifier, because it sometimes operates top-down and sometimes bottom-up. =
When working bottom-up, the simplifier first sees only the %e, and it would=
 have to make a decision right at that moment whether to convert it to a fl=
oat or not. However, it doesn&#39;t know if the %e is a standalone %e or an=
 %e^(...). It cannot know.</div><div dir=3D"auto"><br></div><div dir=3D"aut=
o">If this conditional conversion of %e to a float were to be done in the e=
valuator instead of in the simplifier, it could be done reliably, since the=
 evaluator works top-down. It first sees the %e^(...) before seeing the %e =
alone, therefore it can make the proper decision.</div><div dir=3D"auto"><b=
r></div><div dir=3D"auto">In conclusion, I see 3 ways forward:</div><div di=
r=3D"auto">1) Leave %enumer broken.</div><div dir=3D"auto">2) Degrade %enum=
er: make it a selective switch for either converting all or no instance of =
%e to a float when numer is true (breaking compatibility).</div><div dir=3D=
"auto">3) Remove all special treatment of %e from the simplifier and let th=
e evaluator do it properly. This would be more consistent with how other co=
nstants are treated, but it also may break some existing code that relies o=
n this special, partly broken, behavior.</div></div></div><br><div class=3D=
"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">Richard Fateman &lt;<a =
href=3D"mailto:[email protected]" target=3D"_blank" rel=3D"noreferrer">fate=
[email protected]</a>&gt; schrieb am Mo., 22. Juni 2026, 18:25:<br></div><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1=
px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div class=3D"=
gmail_default" style=3D"font-family:arial,sans-serif;font-size:small">I agr=
ee with Stavros on this.</div><div class=3D"gmail_default" style=3D"font-fa=
mily:arial,sans-serif;font-size:small">Note that ((mexp) 1) would be a clum=
sy way of representing what is now %e...</div><div class=3D"gmail_default" =
style=3D"font-family:arial,sans-serif;font-size:small"><br></div></div><br>=
<div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Ju=
n 22, 2026 at 9:09=E2=80=AFAM Stavros Macrakis &lt;<a href=3D"mailto:macrak=
[email protected]" rel=3D"noreferrer noreferrer" target=3D"_blank">macrakis@gmai=
l.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:=
1ex"><div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_default" style=
=3D"font-family:georgia,serif;font-size:small;color:rgb(51,0,0)"><span styl=
e=3D"font-family:Arial,Helvetica,sans-serif;background-color:transparent;co=
lor:rgb(34,34,34)">On Mon, Jun 22, 2026 at 2:42=E2=80=AFAM Robert Dodier &l=
t;<a href=3D"mailto:[email protected]" rel=3D"noreferrer noreferrer" =
target=3D"_blank">[email protected]</a>&gt; wrote:</span></div></div>=
<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex=
">On Wed, Jun 10, 2026 at 6:56=E2=80=AFAM David Scherfgen via Maxima-discus=
s<br>
&lt;<a href=3D"mailto:[email protected]" rel=3D"noreferr=
er noreferrer" target=3D"_blank">[email protected]</a>&g=
t; wrote:<br><span class=3D"gmail_default" style=3D"font-family:georgia,ser=
if;font-size:small;color:rgb(51,0,0)">...</span>Stepping back a bit, I beli=
eve it would be better overall to represent<br>
the exponential function as something like ((MEXP) ...) instead of<br>
((MEXPT) $%E ...) mostly because the former is more fundamental<span class=
=3D"gmail_default" style=3D"font-family:georgia,serif;font-size:small;color=
:rgb(51,0,0)">...</span></blockquote><div><br></div><div class=3D"gmail_def=
ault" style=3D"font-family:georgia,serif;font-size:small;color:rgb(51,0,0)"=
>That is not a good idea. One of the basic Maxima conventions is to minimiz=
e duplication in representations; and <a href=3D"https://en.wikipedia.org/w=
iki/Don%27t_repeat_yourself" rel=3D"noreferrer noreferrer" target=3D"_blank=
">Don&#39;t Repeat Yourself</a>=C2=A0is just standard good software enginee=
ring practice. So for example, Maxima treats <b>a-b</b>=C2=A0as <b>a+(-1)*b=
</b>=C2=A0rather than having a special subtraction operator. Representing <=
b>%e^x </b>as <b>exp(x)</b>=C2=A0would mean that all the simplification log=
ic for exponentials would have to be duplicated so that e.g.=C2=A0<b>exp(x)=
*exp(y) =3D&gt; exp(x+y)</b>. It would mean adding an additional clause to =
pretty much every function that dispatches on operator=C2=A0e.g. a separate=
 clause for=C2=A0<b>diff(exp(x),...)=C2=A0 </b>vs.=C2=A0<b>diff(2^x,...)</b=
>. Presumably <b>simpexpt</b>=C2=A0would canonicalize <b>%e^x </b>to <b>exp=
(x)</b>, so at least=C2=A0<b style=3D"background-color:transparent">%e^x-</=
b><b style=3D"background-color:transparent">exp(x) </b><span style=3D"backg=
round-color:transparent">would simplify to zero. I&#39;m not concerned abou=
t the effort to do this, nor even the risk of missing cases or introducing =
new bugs -- I&#39;m concerned that every time one piece of functionality is=
 expressed in two different ways, it=C2=A0bloats the code base and makes it=
 harder to understand and to maintain.</span></div><div class=3D"gmail_defa=
ult" style=3D"font-family:georgia,serif;font-size:small;color:rgb(51,0,0)">=
<span style=3D"background-color:transparent"><br></span></div><div class=3D=
"gmail_default" style=3D"font-family:georgia,serif;font-size:small;color:rg=
b(51,0,0)"><span style=3D"background-color:transparent">True, there are cas=
es where we have redundant functions. We could canonicalize <b>gamma(x) </b=
>to <b>(x-1)! </b>or vice versa; and=C2=A0<b>sin(x) </b>to <b>cos(x-%pi/2)<=
/b>, etc. Or, to take the notion of using the &quot;most fundamental&quot; =
representation to its logical conclusion, simply represent trig/hyperbolic =
functions with <b>exp</b>=C2=A0(i.e.=C2=A0<b>exponentialize</b>=C2=A0them a=
ll).=C2=A0</span><span style=3D"background-color:transparent">Actually, I <=
/span><i style=3D"background-color:transparent">do</i><span style=3D"backgr=
ound-color:transparent">=C2=A0think that it would be a good idea for </span=
><b style=3D"background-color:transparent">gamma/!</b><span style=3D"backgr=
ound-color:transparent">=C2=A0(with them being treated as selectable presen=
tation options), but that&#39;s another discussion.</span></div></div></div=
>
_______________________________________________<br>
Maxima-discuss mailing list<br>
<a href=3D"mailto:[email protected]" rel=3D"noreferrer n=
oreferrer" target=3D"_blank">[email protected]</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/maxima-discuss" rel=
=3D"noreferrer noreferrer noreferrer" target=3D"_blank">https://lists.sourc=
eforge.net/lists/listinfo/maxima-discuss</a><br>
</blockquote></div>
_______________________________________________<br>
Maxima-discuss mailing list<br>
<a href=3D"mailto:[email protected]" rel=3D"noreferrer n=
oreferrer" target=3D"_blank">[email protected]</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/maxima-discuss" rel=
=3D"noreferrer noreferrer noreferrer" target=3D"_blank">https://lists.sourc=
eforge.net/lists/listinfo/maxima-discuss</a><br>
</blockquote></div>

--0000000000000fe1d20654da6707--


--===============6567737254904579071==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


--===============6567737254904579071==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============6567737254904579071==--