http://qs1969.pair.com?node_id=11133495


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

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

-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

Replies are listed 'Best First'.
Re^5: Euler's identity in Raku
by syphilis (Archbishop) on Jun 04, 2021 at 12:56 UTC
    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
Re^5: Euler's identity in Raku
by syphilis (Archbishop) on Jun 05, 2021 at 01:43 UTC
    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
      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 ...https://randomascii.wordpress.com/2013/07/16/floating-point-determinism/ 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.
        There may be a world where a language can do identity / symbol math ...

        WRT sin() and cos(), I believe it's actually fairly simple to have them return the exact rational result when applicable - as, UIM, this is only ever applicable for arguments 0, pi/6 (sin only), pi/3 (cos only), pi/2 and pi.
        These cases can be hard coded to return the exact correct value. (Of course, that coding has to also allow for integer multiples of those values.)
        It also calls for a function that takes a rational (p/q) value as it's arg.

        So, instead of calling sin(1 * 3.1415926535897931) and getting a non-zero result, we call (say) sinpi(1) and have it return the hard coded result of zero.
        If the arg given to our sinpi() function is not one of these "special values" (ie 0, 1/6, 1/3, 1/2 or 1 - or a multiple thereof), then sinpi($arg) simply returns sin($arg * 3.1415926535897931)

        ... - indeed there are cpan packages for this kind of thing

        Do you know if there are any there that have sin/cos implementations that return exact results for all of those special values ?

        Cheers,
        Rob