Re: [EXTERNAL] Re: 1-button calculator ~ "all elementary fns from a single operator"
Raymond Toy <[email protected]> Sun, 3 May 2026 14:48:31 -0700
| Newsgroups | gmane.comp.mathematics.maxima.general |
|---|---|
| Message-ID | <[email protected]> |
On 5/3/26 2:37 PM, Henry Baker wrote: > Another potential use case for EML representation: > > A graphical *plotting* program, which obviously requires lots of > numerical calculations (presumably, at least one calculation per point). > > Once again, trying to remember which functions a particular plot > package will recognize is a nightmare, unless you ask Google (or some > other AI) to do the plotting for you. An IEEE/ISO *standard* for > these elementary functions would provide a far easier interface than > currently existing plotting packages. > I would imagine any reasonably useful plotting program ,like gnuplot, would already have all of the elementary functions defined. And isn’t that all the functions that EML supports? It would do any of the other special functions that would be interesting to plot, like, say, gamma. Or a erfc. > > -----Original Message----- > From: Stavros Macrakis <[email protected]> > Sent: May 3, 2026 2:17 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" > > 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 & 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 ​ _______________________________________________ Maxima-discuss mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/maxima-discuss