I see your point much more clearly now, thank you.

That makes sense, and I completely agree. Also, I see what you mean about
Sebastian's point 4a. Hmm.

Jason

On Tue, Oct 25, 2022 at 3:58 PM Brian Bi <bbi5291_at_[hidden]> wrote:

> I feel that you didn't really address the point I raised.
>
> If we had std::cbrt(z) for complex arguments alone, it would make sense to
> define it as std::pow(z, 1.0/3.0). But the simultaneous presence of that
> overload *and* the one for reals, such that the two do not agree when
> restricted to the real line, that would likely cause great confusion to
> programmers.
>
> Another way of saying it is that there's a general design principle that
> if you're going to have multiple overloads of a function, you shouldn't
> need to know which one is going to get called in order to know that it's
> going to do what you want. The proposal to add std::cbrt(std::complex<T> z)
> with the semantics of std::pow(z, 1.0/3.0) violates that principle.
>
> Sebastian's point (4a) would avoid this problem.
>
> On Tue, Oct 25, 2022 at 3:44 PM Jason C via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>> Hi Sebastian,
>>
>> I just replied to Brian Bi elsewhere in this thread at the same time you
>> wrote that, and I think the reply applies here too.
>>
>> What about just having std::cbrt(z) return whatever pow(z, 1/3) returns?
>>
>> The idea is, just as sqrt() arbitrarily returns the positive root, cbrt()
>> can return whatever root as well. And then, just as it's trivial to get the
>> *other* root given sqrt()'s result (multiply by -1), it's also
>> relatively straightforward to get the other two roots given cbrt()'s result
>> (rotate +/- 120 deg in complex plane; as illustrated in de Moivre's
>> formula). It doesn't *really* matter which root is returned.
>>
>> And then you'd get consistency with pow(), which is good.
>>
>> Does that seem reasonable?
>>
>> Jason
>>
>> On Tue, Oct 25, 2022 at 3:29 PM Sebastian Wittmeier via Std-Proposals <
>> std-proposals_at_[hidden]> wrote:
>>
>>> 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]>
>>> 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]>
>>> 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]> 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]
>>> 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
>>>
>>> --
>>> Std-Proposals mailing list
>>> 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
>>
>
>
> --
> *Brian Bi*
>