exp(x) is silently read as a product, so exp equations get wrong answers #730

exp is the ordinary name for the exponential function in every other CAS — sympy, Mathematica, MATLAB, numpy — and the grammar does not have it.

It does not fail. It falls through to implicit multiplication, the rule that lets a(b + c) mean a * (b + c), and comes out as the product of an undeclared variable named exp with the argument:

"exp(x)".ToEntity()          =>  exp * x
"exp(1)".ToEntity().Evaled   =>  exp

Nothing is said about it, so the misreading propagates into an answer that looks like an answer:

"exp(x) - 3 * x".ToEntity().SolveEquation("x")   =>  { 0 }

0 is a root of exp * x - 3 * x. It is not a root of e^x - 3x, which has two real ones near 0.6190612867 and 1.5121345517. So this is a wrong answer to a question the library misread, rather than a refusal to answer a question it does not support.

This is the same shape as the arcsinh case fixed earlier — a name that looks like a function, is not one, and is quietly absorbed by implicit multiplication. The difference is that arcsinh is a misnomer and was right to refuse, whereas exp names something the library already has: e^x.

Suggested fix: add exp( to AngouriMath.g mapping to MathS.Pow(MathS.e, arg), rather than a new node — powers of e already differentiate, integrate and simplify correctly, and a distinct Expf would have to be taught all of it again.

Found while measuring the numerical solver for #115.