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

--===============2513203297305575690==
Content-Type: multipart/alternative; boundary="0000000000000889aa0654da046f"

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

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 <[email protected]=
m> wrote:

> On Mon, Jun 22, 2026 at 2:42=E2=80=AFAM Robert Dodier <robert.dodier@gmai=
l.com>
> wrote:
>
>> On Wed, Jun 10, 2026 at 6:56=E2=80=AFAM David Scherfgen via Maxima-discu=
ss
>> <[email protected]> wrote:
>> ...Stepping back a bit, I believe it would be better overall to represen=
t
>> 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* a=
s
> *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)*e=
xp(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 *di=
ff(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 cases
> or introducing new bugs -- I'm concerned that every time one piece of
> functionality is expressed in two different ways, it bloats the code base
> 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). Ac=
tually,
> I *do* think that it would be a good idea for *gamma/!* (with them being
> treated as selectable presentation options), but that's another discussio=
n.
> _______________________________________________
> Maxima-discuss mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>

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

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,sa=
ns-serif;font-size:small">I agree with Stavros on this.</div><div class=3D"=
gmail_default" style=3D"font-family:arial,sans-serif;font-size:small">Note =
that ((mexp) 1) would be a clumsy way of representing what is now %e...</di=
v><div class=3D"gmail_default" style=3D"font-family:arial,sans-serif;font-s=
ize:small"><br></div></div><br><div class=3D"gmail_quote gmail_quote_contai=
ner"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Jun 22, 2026 at 9:09=E2=
=80=AFAM Stavros Macrakis &lt;<a href=3D"mailto:[email protected]">macraki=
[email protected]</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin: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" s=
tyle=3D"font-family:georgia,serif;font-size:small;color:rgb(51,0,0)"><span =
style=3D"font-family:Arial,Helvetica,sans-serif;background-color:transparen=
t;color:rgb(34,34,34)">On Mon, Jun 22, 2026 at 2:42=E2=80=AFAM Robert Dodie=
r &lt;<a href=3D"mailto:[email protected]" target=3D"_blank">robert.d=
[email protected]</a>&gt; wrote:</span></div></div><div class=3D"gmail_quote"=
><blockquote class=3D"gmail_quote" style=3D"margin: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-discuss<br>
&lt;<a href=3D"mailto:[email protected]" target=3D"_blan=
k">[email protected]</a>&gt; wrote:<br><span class=3D"gm=
ail_default" style=3D"font-family:georgia,serif;font-size:small;color:rgb(5=
1,0,0)">...</span>Stepping back a bit, I believe 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" target=3D"_blank">Don&#39;t Repeat Yourself</a=
>=C2=A0is just standard good software engineering 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 logic 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 tha=
t 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-colo=
r:transparent">exp(x) </b><span style=3D"background-color:transparent">woul=
d simplify to zero. I&#39;m not concerned about 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 w=
ays, it=C2=A0bloats the code base and makes it harder to understand and to =
maintain.</span></div><div class=3D"gmail_default" style=3D"font-family:geo=
rgia,serif;font-size:small;color:rgb(51,0,0)"><span style=3D"background-col=
or:transparent"><br></span></div><div class=3D"gmail_default" style=3D"font=
-family:georgia,serif;font-size:small;color:rgb(51,0,0)"><span style=3D"bac=
kground-color:transparent">True, there are cases where we have redundant fu=
nctions. We could canonicalize <b>gamma(x) </b>to <b>(x-1)! </b>or vice ver=
sa; and=C2=A0<b>sin(x) </b>to <b>cos(x-%pi/2)</b>, etc. Or, to take the not=
ion 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 all).=C2=A0</span><span style=
=3D"background-color:transparent">Actually, I </span><i style=3D"background=
-color:transparent">do</i><span style=3D"background-color:transparent">=C2=
=A0think that it would be a good idea for </span><b style=3D"background-col=
or:transparent">gamma/!</b><span style=3D"background-color:transparent">=C2=
=A0(with them being treated as selectable presentation options), but that&#=
39;s another discussion.</span></div></div></div>
_______________________________________________<br>
Maxima-discuss mailing list<br>
<a href=3D"mailto:[email protected]" target=3D"_blank">M=
[email protected]</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/maxima-discuss" rel=
=3D"noreferrer" target=3D"_blank">https://lists.sourceforge.net/lists/listi=
nfo/maxima-discuss</a><br>
</blockquote></div>

--0000000000000889aa0654da046f--


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


--===============2513203297305575690==
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

--===============2513203297305575690==--