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

--===============7922255348678704288==
Content-Type: multipart/alternative; boundary="0000000000004ee2970654d9da09"

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

On Mon, Jun 22, 2026 at 2:42=E2=80=AFAM Robert Dodier <robert.dodier@gmail.=
com>
wrote:

> On Wed, Jun 10, 2026 at 6:56=E2=80=AFAM David Scherfgen via Maxima-discus=
s
> <[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 *diff(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). Actually, I *do* thi=
nk
that it would be a good idea for *gamma/!* (with them being treated as
selectable presentation options), but that's another discussion.

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

<div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_default" style=3D"fon=
t-family:georgia,serif;font-size:small;color:rgb(51,0,0)"><span style=3D"fo=
nt-family:Arial,Helvetica,sans-serif;background-color:transparent;color:rgb=
(34,34,34)">On Mon, Jun 22, 2026 at 2:42=E2=80=AFAM Robert Dodier &lt;<a hr=
ef=3D"mailto:[email protected]">[email protected]</a>&gt; wrote=
:</span></div></div><div class=3D"gmail_quote gmail_quote_container"><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">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">Don&#39;t Repeat Yourself</a>=C2=A0is just sta=
ndard 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 subtracti=
on 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 addi=
ng an additional clause to pretty much every function that dispatches on op=
erator=C2=A0e.g. a separate clause for=C2=A0<b>diff(exp(x),...)=C2=A0 </b>v=
s.=C2=A0<b>diff(2^x,...)</b>. Presumably <b>simpexpt</b>=C2=A0would canonic=
alize <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"background-color:transparent">would simplify to zero.=
 I&#39;m not concerned about the effort to do this, nor even the risk of mi=
ssing cases or introducing new bugs -- I&#39;m concerned that every time on=
e 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></d=
iv><div class=3D"gmail_default" style=3D"font-family:georgia,serif;font-siz=
e: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,ser=
if;font-size:small;color:rgb(51,0,0)"><span style=3D"background-color:trans=
parent">True, there are cases where we have redundant functions. We could c=
anonicalize <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 &q=
uot;most fundamental&quot; representation to its logical conclusion, simply=
 represent trig/hyperbolic functions with <b>exp</b>=C2=A0(i.e.=C2=A0<b>exp=
onentialize</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 woul=
d be a good idea for </span><b style=3D"background-color:transparent">gamma=
/!</b><span style=3D"background-color:transparent">=C2=A0(with them being t=
reated as selectable presentation options), but that&#39;s another discussi=
on.</span></div></div></div>

--0000000000004ee2970654d9da09--


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


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

--===============7922255348678704288==--