Comment by lmf4lol
4 hours ago
Stupid question maybe (I am no mathematician), but aren't exp and ln really primitives? Aren't they implemented in terms of +,-,/,* etc? Or do we assume that we have an infinite lookup table for all possible inputs?
4 hours ago
Stupid question maybe (I am no mathematician), but aren't exp and ln really primitives? Aren't they implemented in terms of +,-,/,* etc? Or do we assume that we have an infinite lookup table for all possible inputs?
> aren't exp and ln really primitives? Aren't they implemented in terms of +,-,/,* etc?
They're primitive in the sense that you can't compute exp(x) or log(x) using a finite combination of other elementary functions for any x. If you allow infinite many operations, then you can easily find infinite sums or products of powers, or more complicated expressions to represent exp and log and other elementary functions.
> Or do we assume that we have an infinite lookup table for all possible inputs?
Essentially yes, you don't necessarily need an "implementation" to talk about a function, or more generally you don't need to explicitly construct an object from simpler pieces: you can just prove it satisfies some properties and that it is has to exist.
For exp(x), you could define the function as the solution to the diffedential equal df/dx = f(x) with initial condition f(0) = 1. Then you would enstablish that the solution exists and it's unique (it follows from the properties of the differential equation), call exp=f and there you have it. You don't necessarily know how to compute for any x, but you can assume exp(x) exists and it's a real number.
You have a gate (called here "eml") that takes x and y and gives `exp(x) - log(y)`. Then you implement all other operations and elementary functions, including addition, multiplication etc, using only compositions of this gate/function (and the constant 1). You don't have addition as you start, you only have eml and 1. You define addition in terms of those.
I think the point here is to explore the reduction of these functions to finite binary trees using a single binary operator and a single stopping constant. The operator used could be arbitrarily complex; the objective is to prove that other expressions in a certain family — in this case, the elementary functions — can be expanded as a finite (often incomplete) binary tree of that same operation.
In other words, this result does not aim to improve computability or bound the complexity of calculating the numerical value. Rather, it aims to exhibit this uniform, finite tree structure for the entire family of elementary expressions.
I think there is still an implicit restriction on the complexity of the operator for this to be interesting. Otherwise you could design an operator which accepts a pair x,y and performs one of 2^k elementary binary operations by reading off the first k bits of x and applying the specified operation on the remainder of x and y. (This is kind of like how real-valued computational models become too powerful for complexity theory to work if you allow bitwise operations.)
Exactly! If you didn't strictly limit the operator's complexity, you could just smuggle a Turing machine in via bitwise logic and turn the whole thing into a parlor trick. The beauty here is that eml(x,y) is a pure, continuous analytical function with no hidden branching whatsoever.
To clarify my earlier point: the author isn't trying to build a practical calculator or generate human-readable algebra. Using exp and ln isn't a cheat code because the goal is purely topological. The paper just proves that this massive, diverse family of continuous math can be mapped perfectly onto a uniform binary tree, without secretly burying a state machine inside the operator.
3 replies →