The fact that there are three cube roots is precisely the problem.

If std::cbrt(z) were defined for complex z, one would expect it to yield std::exp(std::log(z)/3) (note that std::log returns the principal value). The problem with this is that if z happens to be a negative real, this will not give the same root as the std::cbrt function for reals (namely the negative real one). It will give the one that is inclined at an angle of +pi/3 from the positive x-axis.

That means there's no good way to define std::cbrt(z) for complex z: it violates either one expectation or the other.

I suspect there is no mainstream programming language that has two overloads of the cube root function---one with domain and codomain R, and one with domain and codomain C. They had to pick one---probably the real one, because the complex one you can emulate using whatever is the equivalent of the complex `pow` function. In the case of C++, the choice has been made for us already in any case.

On Tue, Oct 25, 2022 at 11:49 AM Dejan Milosavljevic via Std-Proposals <std-proposals@lists.isocpp.org> wrote:
Cubic root have three solutions.
What is the rule to uniquely pick the first one?
Rest of them we can have by multiply with cbrt( {+1,0} );

My proposal for complex cbrt:
 template< typename T/*number like*/>
  std::complex<T> cbrt(  std::complex<T>  const& c, int index =0 /*  which root to use is defined by ( index  % 3)  0,1 or 2 */  );

This might be too complex.
Any idea to make it simple?

On Tue, Oct 25, 2022 at 5:01 PM Jason C via Std-Proposals <std-proposals@lists.isocpp.org> wrote:
<complex> is conspicuously missing cbrt(). 

If I put together a proposal to add std::cbrt(std::complex) to <complex>, would there be any interest?

Any thoughts?

Jason
--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals


--
Brian Bi