Hi Jason, ordering the roots per se is probably not the problem. But getting the root at the expected position is:   If the first solution is identical to x=exp(z^(1/3)), i.e. -pi/3 < arg(z) <= pi/3 then the next roots could continue counter-clockwise.   Compared to the real function: The cbrt(positive double) would be always the first of three roots of this complex function. The cbrt(negative double) would be always the second of three roots defined this way. The cbrt(negative double) when presented to the function as (negative double - epsilon*i)                        would be always the third of three roots.     So there are 6 possibilities: 1) define cbrt(complex) not at all 2) define cbrt(complex) as exp(z^(1/3)) 3) define cbrt(complex) as the root with the largest real magnitude    That is the same result as cbrt(double) 4a) define two functions cbrt_principal (2) and cbrt_maxreal (3)    safer solution 4b) use a second parametercbrt(double, tag)     with tag=complex::principal_root or complex::maxreal (type, enum, ...) 5) return a list of all three roots    caller possibly would have to sort (see above, where the position of maxreal could be any of the three) 6) return the nth root by provided index    could lead to several repeated calls to function, which is wasteful, especially if caller has to sort the results afterwards, when looking for (3)   I think 4) is the nicest alternative of the ones presented. Some math / numerically oriented programming languages provide 5), most (all?) others provide 2), some (Julia) have the same discussion and stay for the moment at 1).   Best, Sebastian   -----Ursprüngliche Nachricht----- Von:Jason C via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Di 25.10.2022 18:41 Betreff:Re: [std-proposals] std::cbrt(std::complex) An:Dejan Milosavljevic <dmilos_at_[hidden]>; CC:Jason C <jason.cipriani_at_[hidden]>; std-proposals_at_[hidden]; On Tue, Oct 25, 2022 at 12:30 PM Jason C <jason.cipriani_at_[hidden] <mailto:jason.cipriani_at_[hidden]> > wrote: Perhaps   template <typename T> std::tuple<std::complex<T>,std::complex<T>,std::complex<T> > cbrt (std::complex<T> const &c)  Although... this then implies that the roots are ordered, and I'm pretty sure there's no predictable and consistent way to ensure some order of the returned roots given that there's no solid definition of ordering for complex number combined with realistic fp precision errors.  I'm starting to think maybe my idea wasn't such a good one after all and this is probably too complicated to make its way into std; users would be better off choosing other implementations that meet their specific needs, probably.  Jason      On Tue, Oct 25, 2022 at 11:48 AM Dejan Milosavljevic <dmilos_at_[hidden] <mailto:dmilos_at_[hidden]> > 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_at_[hidden] <mailto:std-proposals_at_[hidden]> > 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_at_[hidden] <mailto:Std-Proposals_at_[hidden]> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals