Date: Tue, 25 Oct 2022 12:04:47 -0400
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
>
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 16:05:01