Re: [EXTERNAL] Re: 1-button calculator ~ "all elementary fns from a single operator"

Yes, you can recognize common subexpressions in Maxima using *optimize*. So
the CSE version of *x^(2/3) *is

block([%1,%2,%3,%4],%1:E(1,1),%2:E(1,E(%1,1)),%3:E(1,E(E(1,%2),1)),
      %4:E(%2,E(E(%3,%1),1)),
      E(E(E(E(1,
              E(E(1,
                  E(1,
                    E(E(1,
                        E(E(E(1,E(E(1,E(1,E(E(1,%4),1))),1)),
                            E(E(%3,
                                E(E(1,
                                    E(E(1,
                                        E(
                                         E(%3,
                                           E(
                                            E(1,

E(E(1,E(%2,E(E(%3,E(%4,1)),1))),
                                                1)),1)),1)),1)),1)),1)),1)),
                      1))),1)),
            E(E(%3,E(E(1,E(E(1,E(1,E(E(1,x),1))),1)),1)),1)),1),1))$

Of course, you can make the representation even more compact if you
recognize subparts like, say, *exp*. And then you're back to conventional
representation.

I don't know why you'd want to Gödel number expressions via EML when you
can just as well look at the linear or tree form of conventional
representations as bitstrings.

This is not a "model of computation". It is just a notation. Of course
Richardson's theorem applies to it, since that only requires *sin*,
rational numbers, arithmetic, and functional composition, a subset of the
calculator functions.

Has *anyone* done *anything* non-trivial with this representation?


On Sun, May 3, 2026 at 2:46 PM Henry Baker <[email protected]> wrote:

> Hi Stavros:
>
>
>
> You are correct re optimizers; I've already been playing with obvious
> optimizations.
>
>
>
> Also, an ideal compiler would detect (& take advantage of) *common
> sub-expressions*; otherwise, you're constantly ( :-) re-calculating the
> simplest things (like constants!). Common subexpressions are trivially
> recognized in Lisp with so-called "hash consing"; e.g., I believe that the
> "Maple" symbolic algebra system routinely does hash consing and memoization.
>
>
>
> Most stack machines -- e.g., Postscript -- have the capabilities to
> rearrange and duplicate items on the stack, which enables common
> subexpressions to avoid recomputation.  (Indeed, I wrote such a compiler
> for a Lisp-like language to Postscript many years ago!)
>
>
>
> Why should someone care about this?
>
>
>
> 1. The linear instructions for the stack machine are *bit-strings* (i.e.,
> positive integers). For example, the bit-string "110" tells the stack
> machine to "push 1; push 1; ELM 0(peration)".
>
>
>
> So we inherit a natural Godel numbering for every elementary function
> (obviously not 1-1).
>
>
>
> 2. Q: does the undecidability of zerop apply to this model of computation ?
>
>
>
> 3. I'm not convinced that this gentleman has found the most elegant set of
> primitives; there may be other primitives with more natural properties.
> For example, the proof of the commutativity of + and * does not appear to
> be simple.  Neither would any of the other standard properties of this
> class of functions be easy to prove -- e.g., distribution of * over +.
>
>
>
> 4. The expansion of traditional mathematical expressions into EML form
> does not appear to "blow up", and if the interconversion can be done
> quickly/efficiently, then this EML form might become a *standard
> representation* of such expressions -- even an "ISO" and/or "IEEE" standard
> -- making it easier to communicate between different languages, symbolic
> algebra systems, etc.
>
>
>
> 5. A standard representation could nail down the *default* interpretations
> of expressions like log(0), etc., so that different systems could avoid the
> messiness of so many different switches/parameters.
>
>
>
>
>
> -----Original Message-----
> From: Stavros Macrakis <[email protected]>
> Sent: May 3, 2026 10:18 AM
> To: Henry Baker <[email protected]>
> Cc: Barton Willis via Maxima-discuss <[email protected]
> >
> Subject: Re: [Maxima-discuss] [EXTERNAL] Re: 1-button calculator ~ "all
> elementary fns from a single operator"
>
>
>
> Thanks for sharing the Python code. It is strange that the author calls
> straightforward macro-expansion a "compiler", but I guess these days you
> can get a degree in CS without taking a compiler class....
>
> This translates easily into Mazima (see end of post). Careful! This does
> *not* guarantee the *minimal* EML expression, or even a reasonable
> approximation to it. For example, *exp(x)-log(y)* is minimally expressed
> as *e(x,y)*, not
>
>
> *e(e(1,e(e(1,e(x,1)),1)),*
> *  e(e(1,e(e(1,y),1)),1)*
>
>
> which is what you get by direct expansion.
>
> What next? "optimizers" for eml expressions?
>
> I still don't see the point. How is it helpful to write *x^(2/3)* as
>
> E(E(E(E(1,
>         E(E(1,
>             E(1,
>               E(E(1,
>
> E(E(E(1,E(E(1,E(1,E(E(1,E(E(1,E(E(1,1),1)),E(E(E(1,E(E(1,E(1,E(E(1,1),1))),1)),E(1,1)),1))),1))),1)),
>                       E(E(E(1,E(E(1,E(1,E(E(1,1),1))),1)),
>                           E(E(1,
>                               E(E(1,
>                                   E(E(E(1,E(E(1,E(1,E(E(1,1),1))),1)),
>                                       E(E(1,
>                                           E(E(1,
>                                               E(E(1,E(E(1,1),1)),
>
> E(E(E(1,E(E(1,E(1,E(E(1,1),1))),1)),
>
> E(E(E(1,E(E(1,1),1)),E(E(E(1,E(E(1,E(1,E(E(1,1),1))),1)),E(1,1)),1)),1)),1))),1)),1)),1)),1)),
>
> 1)),1)),1)),1))),1)),E(E(E(1,E(E(1,E(1,E(E(1,1),1))),1)),E(E(1,E(E(1,E(1,E(E(1,x),1))),1)),1)),1)),1),1)
>
>
> --------------------------
>
>  /* write expression using eml */
>
> eml_exp(z):= e(z, 1) ;
> eml_log(z):= e(1, eml_exp(e(1, z))) ;
> eml_zero():= eml_log(1) ;
> eml_sub(a, b):= e(eml_log(a), eml_exp(b)) ;
> eml_neg(z):= eml_sub(eml_zero(), z) ;
> eml_add(a, b):= eml_sub(a, eml_neg(b)) ;
> eml_inv(z):= eml_exp(eml_neg(eml_log(z))) ;
> eml_mul(a, b):= eml_exp(eml_add(eml_log(a), eml_log(b))) ;
> eml_div(a, b):= eml_mul(a, eml_inv(b)) ;
> eml_pow(a, b):= eml_exp(eml_mul(b, eml_log(a))) ;
> eml_one():= 1;
> eml_two():= eml_add(1, 1);
> eml_double(z):= eml_add(z, z);
>
>
> /* expand back */
>
> eml(a,b):=eexp(a)-elog(b);
> eexp(a):=if a=inf then inf elseif a=minf then 0 else exp(a);
> elog(a):= if a=inf then inf elseif a=0 then minf else log(a);
>
> load("opsubst");
> expand_eml(expr) := block([sub: opsubst('eml,'e,expr)], ev(sub,nouns));
>
>
> On Sun, May 3, 2026 at 12:33 PM Henry Baker <[email protected]> wrote:
>
>> OK, I looked at the Python3 code for the EML compiler, and it looks like
>> it would be trivial to translate its formulae into Maxima using pattern
>> matching.
>>
>> For example, here are some of the Python3 functions:
>>
>> def EML(a, b): return f"EML[{a},{b}]"
>> def eml_exp(z): return EML(z, "1") # Exp[z]
>> def eml_log(z): return EML("1", eml_exp(EML("1", z))) # Log[z]
>> def eml_zero(): return eml_log("1") # 0 = Log[1]
>> def eml_sub(a, b): return EML(eml_log(a), eml_exp(b)) # a - b
>> def eml_neg(z): return eml_sub(eml_zero(), z) # -z
>> def eml_add(a, b): return eml_sub(a, eml_neg(b)) # a + b
>> def eml_inv(z): return eml_exp(eml_neg(eml_log(z))) # 1/z
>> def eml_mul(a, b): return eml_exp(eml_add(eml_log(a), eml_log(b))) # a*b
>> def eml_div(a, b): return eml_mul(a, eml_inv(b)) # a/b
>> def eml_pow(a, b): return eml_exp(eml_mul(b, eml_log(a))) # a^b
>> def eml_one(): return "1"
>> def eml_two(): return eml_add("1", "1")
>> def eml_double(z): return eml_add(z, z)
>>
>> Thus, in Maxima
>> matchdeclare(z,all);
>> tellsimp(exp(z),EML(z,1));
>> tellsimp(log(z),EML(1,exp(EML(1,z))));
>>
>> However, such a pattern-matching compiler would have a bigger problem
>> with sums and products, and an even bigger problem with converting
>> constants -- e.g., integers, rationals, floats.
>>
>> The good news: EML compiling and simplification provide a pretty decent
>> workout for Maxima, and would likely make some pretty good test cases
>> and/or benchmarks.
>>
>> -----Original Message-----
>> From: Henry Baker <[email protected]>
>> Sent: May 2, 2026 8:53 AM
>> To: Przemek Klosowski via Maxima-discuss <
>> [email protected]>
>> Subject: Re: [Maxima-discuss] [EXTERNAL] Re: 1-button calculator ~ "all
>> elementary fns from a single operator"
>>
>> OK, I downloaded the "EML compiler" from here:
>>
>> https://github.com/VA00/SymbolicRegressionPackage/tree/master
>>
>> The EML compiler requires python3 &amp; numpy (and probably other stuff
>> that I might already have installed).
>>
>> I then did a trivial script to convert from Mathematica expressions to
>> Maxima expressions.
>>
>> EML requires that log(0)=minf, so I defined mylog(x):=if (x=0) then minf
>> else log(x), and used mylog(x) instead of log(x) in the definition of eml.
>>
>> However, I now require that %e^minf = 0.
>>
>> What is the magic in Maxima to make this happen? I did "? minf", but that
>> didn't provide any help.
>>
>> -----Original Message-----
>> From: Henry Baker
>> Sent: May 1, 2026 11:23 AM
>> To: Przemek Klosowski via Maxima-discuss
>> Subject: Re: [Maxima-discuss] [EXTERNAL] Re: 1-button calculator ~ "all
>> elementary fns from a single operator"
>>
>> Obviously, Google was confused.
>>
>> Q: If z = exp(x)-log(y), then x = log(z + log(y)) might look a tad better
>> ? Is this log(z+log(y)) function universal in the same sense as eml() ?
>>
>> Q: if we have a 1BC expression for f(x)=y, can we then trivially compute
>> x=f^-1(y) ?
>>
>> Q: The 1BC paper seems to want to rely on functions defined over the
>> reals; I suspect that functions defined over the complex numbers might give
>> additional 1BC results that might be prettier ? Perhaps the constant %pi*%i
>> might work to force things into the complex plane ?
>>
>> Q: I've always had a fondness for asinh(x), as it is bijective onto the
>> reals, and has many of the same properties/characteristics as "gradual
>> underflow" floating point numbers. I'm wondering if it could be part of a
>> universal 1BC function ?
>>
>> -----Original Message-----
>> From: Przemek Klosowski via Maxima-discuss
>> Sent: May 1, 2026 9:24 AM
>> To:
>> Subject: Re: [Maxima-discuss] [EXTERNAL] Re: 1-button calculator ~ "all
>> elementary fns from a single operator"
>>
>> > BTW, Google just told me that the obvious differential equation for >
>> eml(x,y) is
>> >
>> > dy/dx = y*exp(x)
>>
>> (%i1) eq:'diff(y,x)=y*exp(x);
>> dy x
>> (%o1) ── = %e y
>> dx
>> (%i2) ode2(eq,y,x);
>> x
>> %e
>> (%o2) y = %e %c
>>
>> what am I missing?
>>
>>
>>
>> _______________________________________________
>> 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
>>
>>
>>
>>
>> _______________________________________________
>> 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
>
>

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