in reply to When 1e-298L != 1e-298L

FWIW: this is the bit pattern you should be seeing for 1e-298:

C:\test>r80test

1e-298
              1e-298 : 00111100 00100001 10000101 11110000 01000110 10
+000010 10010011 11110000 11101011 01001110
                       smmmmmmm mmmmmmmm ffffffff ffffffff ffffffff ff
+ffffff ffffffff ffffffff ffffffff ffffffff
s = sign bit
m = 15-bit mantissa
f = 64-bit fraction

[download]
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.

Replies are listed 'Best First'.
Re^2: When 1e-298L != 1e-298L
by syphilis (Archbishop) on Oct 24, 2013 at 23:59 UTC
    C:\test>r80test

    Is "r80test" readily available ? (Could be handy.)

    kcott's post demonstrates that the discrepancy also occurs when the nvtype is 'double' - but not universally according to some quick testing that I've just done. (The discrepancy occurs with gcc-4.6.3 on linux, and MSVC++ 7.0 on MS Windows, but not gcc-4.7.0 on MS Windows. In all instances the compiler I've used is the compiler that actually built perl. It seems that the behaviour does depend upon the compiler in use, not upon the version number of perl, but that's not properly tested yet.)

    I've just rewritten the demo code so that it's also portable to perls whose nvtype is 'double'. (See my reply to kcott's post.)

    And now I find that the mpfr library is providing varying results on linux and windows. It shouldn't do that, but I'll have to check the versions of mpfr that I'm running. (It may simply be a bug in an earlier version that has been fixed.)

    Thanks Buk.

    Cheers,
    Rob
[reply]
      Is "r80test" readily available ? (Could be handy.)

      It's written in D, which has a native 80-bit FP type available. The code looks like this:

      import std.stdio;
import std.format;

void main( string[] args ) {
    real r;
    ubyte *ubp = cast(ubyte*)&r;
    
    foreach( line; stdin.byLine ) {
        formattedRead( line, " %f ", &r );
        writef( "%20.18g : ", r );
        for( int i = r.sizeof -1; i >= 0; --i ) {
            writef( "%08.8b ", ubp[i] );
        }
        writeln();
    }
}

      [download]

      If you don't want to be bothered with installing/learning D, I can send you the executable?

      With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
[d/l]
        If you don't want to be bothered with installing/learning D, I can send you the executable?

        Send it over would be great !! (I'll /msg you the address.)
        Having another tool that outputs this info would be handy. I'm currently using a "print_binary" function from tests/tmpfr_set_ld.c (in the mpfr source) but it purports to show me the actual value I pass it, not the correct value ... and it's starting to look like the 2 can differ.

        At some point I might like to give D a try. I see that there's a GCC variant (gcd), but I gather that it's the one provided by Digital Mars (dmd, version 2) that would normally be recommended ?

        Cheers,
        Rob
[reply]

In Section Seekers of Perl Wisdom