in reply to Re: Euler's identity in Raku
in thread Euler's identity in Raku

Wouldn't e have to be pure also?

Replies are listed 'Best First'.
Re^3: Euler's identity in Raku
by syphilis (Archbishop) on Jun 03, 2021 at 06:14 UTC
    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.)


      Copying Rob's one-liner into my system gives yet another answer:


      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

        Copying Rob's one-liner into my system gives yet another answer:

        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.

        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
        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.