in reply to Re^5: test fails on 64bit uselongdouble Perl
in thread test fails on 64bit uselongdouble Perl

You can always just round to the nearest integer at the end

Not quite. See my earlier post

  • Comment on Re^6: test fails on 64bit uselongdouble Perl

Replies are listed 'Best First'.
Re^7: test fails on 64bit uselongdouble Perl
by moritz (Cardinal) on Oct 29, 2009 at 21:53 UTC
    If the desired result is an integer, and the numeric errors are small, there's no need to correctly or robustly round 5.5, so I don't see how your earlier post applies here.
    Perl 6 - links to (nearly) everything that is Perl 6.
      Rounding to the nearest integers gives an error of +/- 1.0 even if the actual error is infinitesimally small. The OP said he's not ok with that.
        Rounding to the nearest integers gives an error of +/- 1.0 even if the actual error is infinitesimally small.

        I don't believe that. Care to explain?

        You do a calculation, and the result is an integer $n. Due to precision limits you get instead $n+$eps, where abs($eps) is small.

        Why wouldn't proper rounding return $n, but $n+1 or $n-1? At least that's how I understood your statement that it gives an error of +/- 1.0, which doesn't make sense to me at all.

        Perl 6 - links to (nearly) everything that is Perl 6.

      The result needs to be an integer but the calculation includes floating-point numbers. Again, my problem is that I'm getting different results on 64bit uselongdouble Perl and may best theory currently is differences in floating-point math on different Perls.

        Yes, I understood that. And yes, there are differences in floating point handling.

        But I still don't get what's wrong with rounding to an integer - care to explain?

        You currently seem to think that an integral result as an outcome is normal, but as far as I can tell it works only accidentally on some perls, even if that's the majority of perls.

        Perl 6 - links to (nearly) everything that is Perl 6.