This is neat, but could someone explain the significance or practical (or even theoretical) utility of it?
Read the paper. On the third page is a "Significance statement".
[deleted]
All elementary functions from a single binary operator
81–90 of 317 posts
Re: All elementary functions from a single binary operator
#82Earlier quoted context omitted.
ah, the paper acknowledges this. my bad for jumping to the diagrams!
On page 11, the paper explicitly states: > EML-compiled formulas work flawlessly in symbolic Mathematica and IEEE754 floating-point… This is because some formulas internally might rely on the following properties of extended reals: ln 0 = −∞, e^(−∞) = 0. And then follows with: > But EML expressions in general do not work ‘out of the box’ in pure Python/Julia or numerical Mathematica. Thus, the paper’s completeness cl…
The author does address this further on page 14 of SI and provides an alternative of:
−z = 1 − (e − ((e − 1) − z))
Re: All elementary functions from a single binary operator
#83Earlier quoted context omitted.
This preprint was written by a researcher at an accredited university with a PhD in physics. I'm sure they know what a vector valued function is. The point of this paper is not to revolutionize how a scientific calculator functions overnight, its to establish a single binary operation that can reproduce the rest of the typical continuous elementary operations via repeated application, analogous to how a NAND or NOR g…
its to establish a single binary operation that can reproduce the rest of the typical continuous elementary operations via repeated application, But he didn't show this though. I skimmed the paper many times. He creates multiple branches of these trees in the last page, so it's not truly a single nested operation.
The formulas are provided in the supplementary information file, as mentioned in the paper. https://arxiv.org/src/2603.21852v2/anc/SupplementaryInformat... You want page 9.
Re: All elementary functions from a single binary operator
#84Can someone explain how is this different from lambda calculus, it seems like you can derive the same in both. I don't understand both well enough and hence the question.
The short answer is that the lambda calculus computes transformations on digital values while this is for building functions that can transform continuous (complex) values.
Re: All elementary functions from a single binary operator
#85Can someone explain how is this different from lambda calculus, it seems like you can derive the same in both. I don't understand both well enough and hence the question.
Any lambda term is equivalent to a combinatory term over a one-point basis (like λxλyλz. x z (y (λ_.z)) [1]). One difference is that lambda calculus doesn't distinguish between functions and numbers, and in this case no additional constant (like 1) is needed.
[1] https://github.com/tromp/AIT/blob/master/ait/minbase.lam
Re: All elementary functions from a single binary operator
#86Can someone explain how is this different from lambda calculus, it seems like you can derive the same in both. I don't understand both well enough and hence the question.
Lamda kind of does this in an analogous form, but does not allow you to derive this particular binary expression as a basis for elementary functions. There is a related concept with Iota [1], which allows you express every combinatoric SKI term and in turn every lambda definable function. But similar to this particular minimalist scientific function expression, it is mostly of interest for reductionist enthusiasts and not for any practical purpose.
Re: All elementary functions from a single binary operator
#87Earlier quoted context omitted.
> Why use splines or polynomials or haphazardly chosen basis functions if you can just fit (gradient descent) your data or wave functions to the proper computational EML tree? Same reason all boolean logic isn't performed with combinations of NAND – it's computationally inefficient. Polynomials are (for their expressivity) very quick to compute.
They are done with transistors though. Transistors form an efficient, single element, universal digital basis. And are a much less arbitrary choice than NAND, vs. NOR, XOR, etc. Using transistors as conceptual digital logic primitives, where power dissipation isn't a thing, Pass Logic is "The Way".
Single transistors aren't yet logic gates by themselves; they are amplifiers with a very specific gain function that makes it possible to use them as switches. Logic gates usually consist of at least two transistors. See https://en.wikipedia.org/wiki/CMOS for an example of how it is done in CMOS technology.
Re: All elementary functions from a single binary operator
#88I made a fun marimo notebook to try and derive these myself. I structured each cell in order based on the diagram at the end of the paper. It uses Sympy to determine if the function is correct or not.
https://gist.github.com/CGamesPlay/9d1fd0a9a3bd432e77c075fb8...
Re: All elementary functions from a single binary operator
#89How would an architecture with a highly-optimized hardware implementation of EML compare with a traditional math coprocessor?
It would almost always be much, much worse. Practical numerical libraries (whether implemented in hardware or software) contain lots of redundancy, because their goal is to give you an optimized primitive as close as possible to the operation you actually want. For example, the library provides an optimized tan(x) to save you from calling sin(x)/cos(x), because one nasty function evaluation (as a power series, lookup table, CORDIC, etc.) is faster than two nasty function evaluations and a divide.
Of course the redundant primitives aren't free, since they add code size or die area. In choosing how many primitives to provide, the designer of a numerical library aims to make a reasonable tradeoff between that size cost and the speed benefit.
This paper takes that tradeoff to the least redundant extreme because that's an interesting theoretical question, at the cost of transforming commonly-used operations with simple hardware implementations (e.g. addition, multiplication) into computational nightmares. I don't think anyone has found a practical application for their result yet, but that's not the point of the work.
Re: All elementary functions from a single binary operator
#90EDIT: please change the article link to the most recent version (as of now still v2), it is currently pointing to the v1 version which misses the figures. I'm still reading this, but if this checks out, this is one of the most significant discoveries in years. Why use splines or polynomials or haphazardly chosen basis functions if you can just fit (gradient descent) your data or wave functions to the proper computati…
From my experience of working in this problem domain for the last year, I'd say it is pretty powerful but the "too good to be true part" comes from that EML buys elegance through exponential expression blow-up. Multiplication alone requires depth-8 trees with 41+ leaves i.e. minimal operator vocabulary trades off against expression length. There's likely an information-theoretic sweet spot between these extremes. It'…
In my experience this exponential expression blow-up is less the result of the approach of decomposing into a minimum of primitives, but rather a result from repetition in expression trees:
If we make the analogy from Bertrand Russel's Principia Mathematica, he derived fully expanded expressions, i.e. trees where the leaves only may refer to the same literals, everyone claimed this madness underscored how formal verification of natural mathematics was a fools errand, but nevertheless we see successful projects like metamath (us.metamath.org) where this exponential blow-up does not occur. It is easy to see why: instead of representing proofs as full trees, the proofs are represented as DAG's. The same optimization would be required for EML to prevent exponential blow-up.
Put differently: if we allow extra buttons besides {1, EML} for example to capture unary functions the authors mentally add an 'x' button so now the RPN calculator has {1, EML, x}; but wait if you want multivariate functions it becomes an RPN calculator with extra buttons {1, EML, x,y,z} for example.
But why stop there? in metamath proofs are compressed: if an expression or wff was proven before in the same proof, it first subproof is given a number, and any subsequent invocations of this N'th subproof refers to this number. Why only recall input parameters x,y,z but not recall earlier computed values/functions?
In fact every proof in metamath set.mm that uses this DAG compressibility, could be split into the main proof and the repeatedly used substatements could be automatically converted to explicitly separate lemma proofs, in which case metamath could dispose of the single-proof DAG compression (but it would force proofs to split up into lemma's + main proof.
None of the proven theorems in metamath's set.mm displays the feared exponential blowup.