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

EML is an almost pessimal representation for both numeric and symbolic
calculation.
It is the Brainfuck of formula representation.

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

> The fellow who wrote the paper has been using this notation to try to
> *compress* numerical data streams.
>
>
>
> There are several motivations:
>
>
>
> 1. Shorter representations than more traditional forms of data compression
> -- e.g., FFT's.
>
>
>
> 2. Better *interpolation* for estimating data not captured originally.
>
>
>
> 3. Suggestions for new physical laws by examining the structure of these
> short representations.
>
>
>
> ---
>
> BTW, just because this "bit-sequence" representation uses only 2
> operations doesn't necessarily make it inefficient to interpret.
>
>
>
> Modern hardware *instruction caches* have gone far beyond trivial table
> lookups, and can now perform certain "peephole" optimizations on-the-fly;
> these may not save instruction *bits*, but still save instruction
> *execution time*.
>
>
>
> For example, an instruction cache for an hypothetical ELM computer would
> be a long bit-string *shift-register*, and one could do a table lookup on
> the leftmost 8 or 16 or 24 bits to find a *macro instruction* which would
> be a pre-compiled *optimized* version of whatever the given instruction
> bitstream wanted to do. Such precompilation would save an enormous amount
> of time, and could also preserve *far more bits of precision* than the
> given instruction bitstream -- e.g., precompiled *constants* could simply
> be *looked up*, so there would be no loss of precision or time in loading
> such constants; the complicated expressions for sin,cos,tan,asin,acos,atan
> etc., would be *recognized* as sin,cos,tan,asin,acos,atan etc., so that
> there would be no time or precision penalty for any of these common
> function patterns.
>
>
>
>
>
> -----Original Message-----
> From: Stavros Macrakis <[email protected]>
> Sent: May 3, 2026 12:21 PM
> To: <[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"
>
>
> 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