in reply to test fails on 64bit uselongdouble Perl

Just like some numbers are periodic in decimal (e.g. 1/3), some numbers are periodic in binary (e.g. 6/10). They cannot be represented exactly using a float since that would require infinite storage.

You shouldn't check if two floats are equal. You should check if two floats are sufficiently identical.

my $calc = (((63 - -90)/.6) * 601) + (360 /.6); ok( abs( $calc - 153855 ) < 0.000000001 ) or diag("Expected 153855. Got $calc");

Replies are listed 'Best First'.
Re^2: test fails on 64bit uselongdouble Perl
by frankcox (Acolyte) on Oct 29, 2009 at 19:18 UTC

    Ahh! Good explanation of issue with .6 ikegami. I missed that

    My real problem is that I get different results with different Perl variants. I need my algorithm to work the same on all Perls.

      Then you have to avoid all floating point numbers. But seriously, that's not a worthy goal. If your algorithms are numerically stable, the errors won't be larger than 1e-18 or so - does that really matter for your purposes?
        My result needs to be an integer and it needs to be the same integer for all Perls. My problem with uselongdouble Perls is that for some values the result is off by one. Sometimes it's one to big and sometimes one to small.

        I need an integer result and it needs to be the same integer for any Perl. My problem with uselongdouble Perls is that the result for most values is the same but for some it's off by one, sometimes high and sometimes low.

        If you're interested, I've included more detail in this RT ticket:

        http://rt.cpan.org/Ticket/Display.html?id=50820

      You can't use floats if differences are a problem. Like I said, with floats, you have to be satisfied with no differences within a tolerance.

        The output of my algorithm is an integer. On all other Perls tested by CPAN Testers I get the same integer. On uselongdouble Perls I usually get the same int too, but for some values I get an integer that is one off, sometimes high and sometime low. It's really just a a lucky fluke that a test happened to use a value that uncovered the bug

        I may have to remove support for these "problem" Perls by aborting the build. I'd rather not do that but it's better than giving wrong results

        If you're interested, there are more details in this RT ticket:

        http://rt.cpan.org/Ticket/Display.html?id=50820