Roots vs fractioned powers?

[WhiteBlackGoose]

That is quite a vague and ambiguous topic when it comes to computational algebra. As we know, n-th root is something whose n-th power is the root's argument. So technically there are a lot of such numbers. The simplest way to represent a root is fractioned powers, e. g. square root of x is x^(1/2).

There we come to another problem: we know that (x ^ a) ^ b = x ^ (a * b), and we know, that 1/2 * 2 = 1. So technically we get that sqrt(x^2) = x which is actually okay to me, but in most common cases it won't be accepted. Reason: principle root.

There're more ambiguous stuff, I might add some more info to this issue. Any thoughts are welcomed and may be discussed in this thread.

[Rafael-SOWNet]

Some measurements for the thread, since the ambiguity is easier to argue about with the current behaviour written down. master at a45a7256, default codomain (complex).

written	node	Simplify	Evaled
sqrt(x)	Powf	sqrt(x)	sqrt(x)
x ^ (1/2)	Powf	sqrt(x)	sqrt(x)
sqrt(x ^ 2)	Powf	sqrt(x ^ 2)	sqrt(x ^ 2)
(x ^ 2) ^ (1/2)	Powf	sqrt(x ^ 2)	sqrt(x ^ 2)
sqrt(-1)	Powf	i	i
(-8) ^ (1/3)	Powf	-2	-2

The library already made the choice this issue is about, in the direction the issue prefers. There is no root node — sqrt(x) is Powf(x, 1/2) — and sqrt(x ^ 2) is not simplified to x. So (x^a)^b = x^(a*b) is not applied unconditionally, which is the guard against the principal-root problem in the body.

(-8) ^ (1/3) = -2 is worth noting as the one that will surprise: the real cube root rather than the principal complex one, which is 1 + i*sqrt(3). That is a deliberate-looking choice and it is inconsistent with sqrt(-1) = i taking the principal branch. If any single thing here deserves an issue of its own, I think it is that pair.

sqrt(x) and x ^ (1/2) are not structurally equal, though they simplify alike — and the cost models rank them differently:

model	sqrt(x)	x ^ (1/2)
Default	10.000	13.000
SmallestTree	3.000	5.000
FewestRadicals	1.003	1.005

Both are counted as one radical by FewestRadicals — that is right, and it is right only since #953, which taught the feature models to read the exponent's value rather than its written node (#950). Before that, an exponent written as 2 ^ (-1) was not seen as a radical at all.

So the practical state is: one representation, two spellings, ranked by size rather than by kind, and no unconditional exponent-merging rule. The remaining ambiguity is the branch question — which root x ^ (1/n) denotes for negative x — and that is where MathS.Settings.Codomain already carries a decision the rules can consult, as Logf now does since #916.