*Wouldn't e have to be pure also?*
You're correct - the inexactness of "e" is also influencing the result.
**UPDATE:** BTW, in perl we can reproduce you're original result with:
`>perl -MMath::Complex -le "print exp(1) ** (pi * i);"
-1+1.22460635382238e-16i
`
Oops ... hang on ... that's **not** exactly the same. (I'm not all that familiar with Raku, so I'm not sure what accounts for that difference.)
Cheers, Rob | [reply] [d/l] |

-1+1.22464679914735e-16i
Using perl -v, my perl is " This is perl 5, version 32, subversion 1 (v5.32.1) built for x86_64-linux-gnu-thread-multi
". Possibly different compilers or options used to build the executables. As somebody who has dealt with floating point issues, 10**(-16) in a operation return like this is frequently noise. I'd not expect perl to return exactly zero to sin(pi) and I don't get it, but 1.22464679914735e-16.
That's hinting at something, but I'm not quite sure what.
Tried (and hopefully succeeded) in fixing the formatting, so my reply isn't in my sig.
Information about American English usage here and here. Floating point issues? Please read this before posting. — emc
| [reply] |

*Copying Rob's one-liner into my system gives yet another answer:*
`-1+1.22464679914735e-16i`
That's the same result as the OP got.
The difference is that perl's print function rounded the final 2 digits away, whereas Raku's didn't.
Now that I'm back home, I can see the same with perl on Ubuntu-20.04.
The figure that I reported came from Windows, so there's a discrepancy in the underlying C libraries.
`C:\>perl -le "printf '%a', 1.2246467991473532e-16;
0x1.1a62633145c07p-53
C:\>perl -le "printf '%a', 1.2246063538223773e-16;
0x1.1a6p-53
`
The latter (which is what windows is reporting) is suspiciously truncated.
With the MPC library, the given inputs produce a result of `-1+2.8954204500590832e-16`.
Cheers, Rob | [reply] [d/l] [select] |

*I'd not expect perl to return exactly zero to sin(pi) and I don't get it, but 1.22464679914735e-16*
The reliance on the sine and cosine trig functions can be seen at https://www.math.toronto.edu/mathnet/questionCorner/complexexp.html.
For the case under consideration in this thread, the imaginary component should be `sin(3.1415926535897931 * log(2.7182818284590451))`
`log(2.7182818284590451)` is calculated to be exactly 1 and, as already noted, `sin(3.1415926535897931)` is calculated to be 1.2246467991473532e-16.
I don't know how the MPC library is coming up with `2.8954204500590832e-16`, but I'm about to ask them about that, and I'll update this post when I get the answer.
**UPDATE:** I've changed my mind - the value returned for these inputs is very sensitive to minute changes in the evaluation of those inputs. For example:
`sisyphus@sisyphus5-desktop:~$ perl -MMath::Complex -E "say sin(pi * 1)
+;"
1.22464679914735e-16
sisyphus@sisyphus5-desktop:~$ perl -MMath::Complex -E "say sin(pi * 0.
+99999999999999994);"
5.66553889764798e-16
`
I don't see much point in investigating further when such a minute alteration to the arguments can make such a large **relative** difference, especially when we consider that the **absolute** difference is so minute.
Cheers, Rob | [reply] [d/l] [select] |

Comment onRe^2: Euler's identity in Raku