[Bug libstdc++/56106] New: complex pow improvements

[Bug libstdc++/56106] New: complex pow improvements

[glisse at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56106

             Bug #: 56106
           Summary: complex pow improvements
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: glisse@gcc.gnu.org


See this discussion for more details:
http://gcc.gnu.org/ml/libstdc++/2013-01/msg00058.html

Several improvements seem possible.

1) in pow(const complex<_Tp>& __x, const _Tp& __y), if _GLIBCXX_USE_C99_COMPLEX
&& !_GLIBCXX_FAST_MATH, we could convert y to a complex and call the libc
version, more accurate than chaining several calls. (I mention
_GLIBCXX_FAST_MATH assuming that the version with polar, exp and log is faster
than the general libc version, I don't know if that is really the case)

2) among the pow(complex,scalar) overloads, those for which scalar is an
integer could be split out and implemented with recursive squaring (as
currently done in C++03 mode for int only). Note that when the exponent is not
-1, 0, 1 or 2, this might also require _GLIBCXX_FAST_MATH ||
!_GLIBCXX_USE_C99_COMPLEX as it may not give anymore the correctly rounded
result.

Note that the libc version may already test for real or small integer
arguments, so we can't expect a huge performance benefit from not calling it in
these cases.

[Bug libstdc++/56106] complex pow improvements

[Alexander.Voigt at desy dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56106

Alexander Voigt <Alexander.Voigt at desy dot de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |Alexander.Voigt at desy dot de

--- Comment #1 from Alexander Voigt <Alexander.Voigt at desy dot de> ---
I would like to support the suggestion 2 to add overloads for
pow(complex,scalar) when scalar is an integer type. 

The reason is that if scalar is an integer type (but not int), the function
pow(complex,scalar) produces (unnecessarily) imprecise results. Here is an
example where scalar is of type int64_t:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#include <complex>
#include <cmath>
#include <iostream>
#include <iomanip>

int main() {
    const std::complex<double> z(0.0, -0.9272952180016123);
    const int64_t n = -11; // precise result if n is of type int
    std::cout << std::setprecision(17) << std::pow(-z, n) << '\n';
    // Output: (-5.6202077021041968e-15,2.2940441836319949)
    // Expected output: (-0,2.2940441836319949)
}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The output of this code snipped when compiling with gcc version 10.2.1 20210110
(Debian 10.2.1-6) as

   g++ bug.cpp
   ./a.out

gives the imprecise real part -5.6202077021041968e-15 (expected real part:
0.0).
When n is changed to type int, the real part is exactly 0.0, as expected.
Adding overloads for (non-int) integral types would thus improve the precision
of the output.