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

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


Replies are listed 'Best First'.
Re^4: Euler's identity in Raku
by swampyankee (Parson) on Jun 04, 2021 at 01:23 UTC

    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.

        There may be a world where a language can do identity / symbol math - indeed there are cpan packages for this kind of thing. But core Raku does not attempt to do that. Raku is (fortunately) pretty simplistic: you get Ints, Rats and Nums (well and Complex but that's another topic). This aligns to mathematics number spaces Integers, Rational and Irrational numbers. Some operations (eg. sqrt(2)) will make an irrational number. Without symbolic math, you lose a little precision in any machine with finite word size and cannot fully restore the initial state with a round trip. Rounding can hide this.
        > my $t=sqrt(2) 1.4142135623730951 > $t ** 2 2.0000000000000004
        sooooo You are plumbing the edges of IEEE754 here ... and very small numbers are subject to all kinds of influences ... here is a good write up ... Back in the day many FPUs did random seed guess for division/sqrt ... even if that practice has become standardised to make the result deterministic (every pass is the same), it certainly will not require each FPU design to guess the same seed. And this ignores the fact that FPU designers will often shortcut full IEEE754 to save on transistors, various compiler settings. Not to rule out frequent chip logic design errors that do not get caught since the test sw will judge any of the near '0' as zero.