On Thu, Aug 30, 2018 at 4:01 AM Paul Moore <p.f.moore@gmail.com> wrote:
On Thu, 30 Aug 2018 at 08:38, Neil Girdhar <mistersheik@gmail.com> wrote:
There are a lot of misunderstandings in this thread. It's probably best
to start by reading up on the roots of unity ( https://en.wikipedia.org/wiki/Root_of_unity). The key ideas are that a real number has two complex square roots, three complex cube roots, and so on.
The complexities of fractional powers aside, the type of a result should not depend on the values of the arguments. So I'm -1 on this change for that reason alone.
Just so you know, it already does depend on the type of the arguments. In [4]: Fraction(2) ** Fraction(1, 2) Out[4]: 1.4142135623730951 In [5]: Fraction(2) ** Fraction(3, 1) Out[5]: Fraction(8, 1) Like a lot of types, Fraction tries to return a Fraction if it can. This is consistent with how math.sqrt of a float returns a float and never a complex, and same for numpy.cbrt. Questions of which root it's appropriate to take are separate, and IMO
the sensible option is to follow the behaviour of float, for which we have
(-1)**(2/3) (-0.4999999999999998+0.8660254037844387j)
But -1 ** Fraction(2, 3) is closer to cube_root(-1 ** 2) than it is to the floating behavior. The reason the floating behavior returns what it does is, if I understand correctly, to try to stay on the same complex branch as the power varies. In other words, we want branch continuity in the power. After all, floating point values have some inaccuracy, and we wouldn't want chaotic behavior, i.e., small changes to the power to have drastic changes to the result. This is not like Fraction where we know that x ** Fraction(1, 3) is a genuine cube root, and so why not return the principal cube, which we know to be real valued for real valued x?
(1)**(2/3) 1.0
(0)**(2/3) 0.0
So current behaviour of Fraction is correct on that basis, IMO.
Paul