Isn't this same problem as doing:
```
small != (big + small) - big
```
?

Compared to the amplitude of the whole complex number, this difference
could be less than error margin.
Another thing this number will be hard to convert to polar form (it
could be possible that both have the same representation).

Simply expecting stable results in this case is nearly impossible,
because many transformations of the whole number are unstable for the
smaller part.


śr., 3 mar 2021 o 17:59 Bell, Ian H. (Fed) via Std-Discussion
<std-discussion_at_[hidden]> napisał(a):
>
> Python must be special casing integer exponents that can be exactly represented in double precision. For instance for an exponent *just* above 2.0, we have a similar problem in Python:
>
> h = 1e-100
> z = -0.1+1j*h
> p = 2.00000001
> print(pow(z, p), pow(z, p).imag/h)
>
> yielding
>
> (0.00999999976974149+3.1415925780626665e-10j) 3.1415925780626666e+90
>
> which is off by ~90 orders of magnitude from the correct value of -0.200000001
>
> -----Original Message-----
> From: Mark Hoemmen <mhoemmen_at_[hidden]>
> Sent: Wednesday, March 3, 2021 11:58 AM
> To: sci_at_[hidden]; std-discussion_at_[hidden]
> Cc: Peter Sommerlad (C++) <peter.cpp_at_[hidden]>; Bell, Ian H. (Fed) <ian.bell_at_[hidden]>
> Subject: Re: [isocpp-sci] [std-discussion] Problems with pow(std::complex<T>, double)
>
> Complex log implementations might want to compute the magnitude as
> sqrt(real(x)*real(x) + imag(x)*imag(x)). This results in loss of accuracy if one of real(x) or imag(x) (the latter in this case) is small relative to the other. Using std::hypot instead could help. I'm a bit busy at the moment but I can study this in more detail if you would like, though I'm sure there are plenty of more qualified experts here :
> - ) .
>
> mfh