Date: Tue, 25 Oct 2022 22:07:54 +0100
Hi,
There is a possible complex cbrt implementation with the following properties:
0. cbrt(z)^3 == z (actually a cube root)
1. It returns the same values for real arguments as the real cbrt,
2. cbrt(-z)=-cbrt(z) (remains an odd function)
The trick/hack is to make it discontinuous on the whole imaginary axis. For pure imaginary numbers the sign of the imaginary part decides which root to take.
Unfortunately cbrt(z)=exp(log(z)/3) does not hold (where log has the branch cut on the negative reals).
I'm not suggesting to include a complex cbrt like this in the standard library, just food for thought. I don't know if a definition like this would be useful.
Cheers,
Lénárd
On 25 October 2022 17:04:47 BST, Brian Bi via Std-Proposals <std-proposals_at_[hidden]> wrote:
>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_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
>>
>
>
>--
>*Brian Bi*
There is a possible complex cbrt implementation with the following properties:
0. cbrt(z)^3 == z (actually a cube root)
1. It returns the same values for real arguments as the real cbrt,
2. cbrt(-z)=-cbrt(z) (remains an odd function)
The trick/hack is to make it discontinuous on the whole imaginary axis. For pure imaginary numbers the sign of the imaginary part decides which root to take.
Unfortunately cbrt(z)=exp(log(z)/3) does not hold (where log has the branch cut on the negative reals).
I'm not suggesting to include a complex cbrt like this in the standard library, just food for thought. I don't know if a definition like this would be useful.
Cheers,
Lénárd
On 25 October 2022 17:04:47 BST, Brian Bi via Std-Proposals <std-proposals_at_[hidden]> wrote:
>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_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
>>
>
>
>--
>*Brian Bi*
Received on 2022-10-25 21:07:59