Re: Inconsistencies and special treatment of %e vs. %pi (and numer, %enumer mess)
Richard Fateman <[email protected]> Mon, 22 Jun 2026 13:25:54 -0700
| Newsgroups | gmane.comp.mathematics.maxima.general |
|---|---|
| Message-ID | <CADB8Zm6S7M6StaGhRSR8bDT3D7c7NaA4RbFVSL=AAfau024piw@mail.gmail.com> |
--===============3781588380169197443== Content-Type: multipart/alternative; boundary="000000000000c8e16c0654dd731e" --000000000000c8e16c0654dd731e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable There is always the possibility of introducing another function, say Exp(z) which can be defined to be as much as %e^(z) as you like, and perhaps governed by additional flags, tellsimp rules, etc. At critical junctures it would be possible to replace Exp(z) with %e^z, or the opposite.. It is entirely possible to write a whole system that not only uses Exp, but Log instead of log... if you don't like the way Maxima does log.. etc. RJF On Mon, Jun 22, 2026 at 9:47=E2=80=AFAM David Scherfgen <d.scherfgen@google= mail.com> wrote: > 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, i= n > fact, it's very difficult if not impossible to make it work in the > simplifier, because it sometimes operates top-down and sometimes bottom-u= p. > When working bottom-up, the simplifier first sees only the %e, and it wou= ld > 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 th= e > %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 compatibilit= y). > 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 reli= es > 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@gm= ail.com> >>> wrote: >>> >>>> On Wed, Jun 10, 2026 at 6:56=E2=80=AFAM David Scherfgen via Maxima-dis= cuss >>>> <[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 tre= ats >>> *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 muc= h >>> 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 *t= o >>> *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 cas= es >>> or introducing new bugs -- I'm concerned that every time one piece of >>> functionality is expressed in two different ways, it bloats the code ba= se >>> 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* think that it would be a good idea for *gamma/!* (with them >>> being treated as selectable presentation options), but that's another >>> discussion. >>> _______________________________________________ >>> 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 >> > --000000000000c8e16c0654dd731e 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">There is always the possibility of introducing an= other function, say Exp(z)=C2=A0 which can be defined to be as much as</div= ><div class=3D"gmail_default" style=3D"font-family:arial,sans-serif;font-si= ze:small">%e^(z) as you like, and perhaps governed by additional flags, tel= lsimp rules, etc.=C2=A0 At critical junctures it would be</div><div class= =3D"gmail_default" style=3D"font-family:arial,sans-serif;font-size:small">p= ossible to replace Exp(z) with %e^z, or the opposite..=C2=A0 It is entirely= possible to write a whole system that not only</div><div class=3D"gmail_de= fault" style=3D"font-family:arial,sans-serif;font-size:small">uses Exp,=C2= =A0 but Log instead of log... if you don't like the way Maxima does log= .. etc.</div><div class=3D"gmail_default" style=3D"font-family:arial,sans-s= erif;font-size:small">RJF</div><div class=3D"gmail_default" style=3D"font-f= amily:arial,sans-serif;font-size:small"><br></div></div><br><div class=3D"g= mail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On = Mon, Jun 22, 2026 at 9:47=E2=80=AFAM David Scherfgen <<a href=3D"mailto:= [email protected]">[email protected]</a>> wrote:<br></= div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor= der-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"auto">Par= t of the current special treatment of %e was introduced for the sole purpos= e of making %enumer "work", i.e. being able to convert a standalo= ne %e to a float, but not an %e in %e^(...) - which isn't a bad idea, i= n my opinion.<div dir=3D"auto"><br><div dir=3D"auto">Unfortunately, it does= n't work, as I showed in my initial message. And, in fact, it's ver= y difficult if not impossible to make it work in the simplifier, because it= sometimes operates top-down and sometimes bottom-up. When working bottom-u= p, the simplifier first sees only the %e, and it would have to make a decis= ion 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.</div><div dir=3D"auto"><br></div><div dir=3D"auto">If this conditiona= l conversion of %e to a float were to be done in the evaluator instead of i= n 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 c= an make the proper decision.</div><div dir=3D"auto"><br></div><div dir=3D"a= uto">In conclusion, I see 3 ways forward:</div><div dir=3D"auto">1) Leave %= enumer broken.</div><div dir=3D"auto">2) Degrade %enumer: make it a selecti= ve switch for either converting all or no instance of %e to a float when nu= mer is true (breaking compatibility).</div><div dir=3D"auto">3) Remove all = special treatment of %e from the simplifier and let the evaluator do it pro= perly. This would be more consistent with how other constants are treated, = but it also may break some existing code that relies on this special, partl= y broken, behavior.</div></div></div><br><div class=3D"gmail_quote"><div di= r=3D"ltr" class=3D"gmail_attr">Richard Fateman <<a href=3D"mailto:fatema= [email protected]" rel=3D"noreferrer" target=3D"_blank">[email protected]</a>>= schrieb am Mo., 22. Juni 2026, 18:25:<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 class=3D"gmail_default" style= =3D"font-family:arial,sans-serif;font-size:small">I agree with Stavros on t= his.</div><div class=3D"gmail_default" style=3D"font-family:arial,sans-seri= f;font-size:small">Note that ((mexp) 1) would be a clumsy way of representi= ng 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, Jun 22, 2026 at 9:09= =E2=80=AFAM Stavros Macrakis <<a href=3D"mailto:[email protected]" rel= =3D"noreferrer noreferrer" target=3D"_blank">[email protected]</a>> wro= te:<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" style=3D"font-family:geo= rgia,serif;font-size:small;color:rgb(51,0,0)"><span style=3D"font-family:Ar= ial,Helvetica,sans-serif;background-color:transparent;color:rgb(34,34,34)">= On Mon, Jun 22, 2026 at 2:42=E2=80=AFAM Robert Dodier <<a href=3D"mailto= :[email protected]" rel=3D"noreferrer noreferrer" target=3D"_blank">r= [email protected]</a>> 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, 2= 026 at 6:56=E2=80=AFAM David Scherfgen via Maxima-discuss<br> <<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'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> 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'm not concerned abou= t 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=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 "most fundamental" = 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'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> </blockquote></div> --000000000000c8e16c0654dd731e-- --===============3781588380169197443== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============3781588380169197443== 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 --===============3781588380169197443==--