http://d.puremagic.com/issues/show_bug.cgi?id=9297

           Summary: Formatting of floating point values in std.format
                    truncates reals to double
           Product: D
           Version: D2
          Platform: x86_64
        OS/Version: Windows
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Phobos
        AssignedTo: nobody@puremagic.com
        ReportedBy: bugzilla@digitalmars.com


--- Comment #0 from Walter Bright <bugzilla@digitalmars.com> 2013-01-11 21:55:36 PST ---
The following from std.format shows the problem:

    n = snprintf(fbuf.ptr, sl, format.ptr, field_width,
            precision, cast(double)v);

It relies on the VC runtime library function snprintf to do the formatting, but that function does not support 80 bit reals.

To fix we'll need to write our own 80 bit formatting routine instead of relying on the host C compiler's.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=9297


hsteoh@quickfur.ath.cx changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hsteoh@quickfur.ath.cx


--- Comment #1 from hsteoh@quickfur.ath.cx 2013-02-26 16:56:01 PST ---
Does gcc/g++ support 80-bit floats? I made a little test program in a Linux environment, and it seems that in spite of the cast, some extra precision is still getting through:

import std.stdio;

void main() {
        // Stuff with way too many digits than the types can handle, to see how
        // far they get.
        enum float phi_f = 1.6180339887_4989484820_4586834365f;
        enum double phi_d = 1.6180339887_4989484820_4586834365;
        enum real phi_r = 1.6180339887_4989484820_4586834365L;

        // The exact digits, taken from:
        //
        //
http://fabulousfibonacci.com/portal/index.php?option=com_content&view=article&id=7&Itemid=17
        //
        // (NOTE: the last digit is actually 6 if we round up the next digit
        // instead of truncating. But built-in types won't even come close to
        // that point).
        string phi_s = "1.618033988749894848204586834365";

        writeln(float.dig);
        writeln(double.dig);
        writeln(real.dig);

        writefln("%.25f", phi_f);
        writefln("%.25f", phi_d);
        writefln("%.25f", phi_r);
        writefln("%s", phi_s);
}


Output:

$ ./test
6
15
18
1.6180340051651000976562500
1.6180339887498949025257389
1.6180339887498948482072100
1.618033988749894848204586834365
$

Notice that the third line, which is the formatting of real, shows up with more matching digits than double. Could this be something to do with the way the Linux C/C++ ABI works (IIRC some floats gets passed in the FPU registers where they retain their 80-bit precision)?

I don't have a way to test this on VC, though.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=9297


Doug Nickerson <Tachyon165@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |Tachyon165@gmail.com


--- Comment #2 from Doug Nickerson <Tachyon165@gmail.com> 2013-09-15 02:40:20 PDT ---
Using DMD 2.063.2 on Win7 64-bit it doesn't appear to be casting to double when compiling with the -m64 flag.  When using the "s" "f" or "a" format characters and a real value I get 0 in the output.  I can manually cast to double and it works fine (truncating though I presume).

Interestingly, when I remove the -m64 option it works for reals and double.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------