Thread overview | |||||
---|---|---|---|---|---|
|
February 20, 2013 "%e" floating point format and exponent digits | ||||
---|---|---|---|---|
| ||||
In Phobos, there are quite a few unit tests (std.format, std.json, ...) which assume that the %e floating point format zero-pads the exponent to (at least) two digits. However, the printf-family functions in the MSVC and MinGW runtimes pad the exponent to *three* digits. For example, 1.223e+24 is printed as "1.223e+024". By extension, this also applies to the std.format (and thus std.stdio) floating point code, which relies on snprintf. What is the correct fix here? Adjusting those unit tests? Doing something crazy along the lines of "if (result[$-4] == 'e' && result[$-3] == '0') { /+ trim zero +/ }"? (How) Is this handled on DMD/Win64? The best way would probably be to just implement floating point printing in D as well, to isolate our code from such C runtime implementation differences. David |
February 20, 2013 Re: "%e" floating point format and exponent digits | ||||
---|---|---|---|---|
| ||||
Posted in reply to David Nadlinger | On 2/20/13, David Nadlinger <see@klickverbot.at> wrote:
> In Phobos, there are quite a few unit tests (std.format,
> std.json, ...) which assume that the %e floating point format
> zero-pads the exponent to (at least) two digits.
I don't know about the exponent problem, but w.r.t. floating point there was a recent bug fixed where this source file:
auto x = 1.0;
Would be converted to this header file:
auto x = 1;
These are then different types. So I've changed how floating-point is written in DMD to always emit "1.0" rather than "1". This also improved diagnostics.
But I wanted to always print at most two digits in this case (e.g. 1.00, 2.00, etc) but couldn't find a good way to do it with sprintf, so currently for floating-point e.g. "1" it prints "1.00000" in diagnostics and header files, which is excessive.
Anyway I would definitely like to see floating-point printing synchronized across multiple compilers and also the D library, to be consistent everywhere.
|
February 22, 2013 Re: "%e" floating point format and exponent digits | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrej Mitrovic | On Wednesday, 20 February 2013 at 22:34:15 UTC, Andrej Mitrovic wrote:
> On 2/20/13, David Nadlinger <see@klickverbot.at> wrote:
>> In Phobos, there are quite a few unit tests (std.format,
>> std.json, ...) which assume that the %e floating point format
>> zero-pads the exponent to (at least) two digits.
>
> I don't know about the exponent problem, but w.r.t. floating point
> there was a recent bug fixed where this source file:
>
> auto x = 1.0;
>
> Would be converted to this header file:
>
> auto x = 1;
>
> These are then different types. So I've changed how floating-point is
> written in DMD to always emit "1.0" rather than "1". This also
> improved diagnostics.%
>
> But I wanted to always print at most two digits in this case (e.g.
> 1.00, 2.00, etc) but couldn't find a good way to do it with sprintf,
> so currently for floating-point e.g. "1" it prints "1.00000" in
> diagnostics and header files, which is excessive.
>
> Anyway I would definitely like to see floating-point printing
> synchronized across multiple compilers and also the D library, to be
> consistent everywhere.
Another related issue is the format of %a. On Windows it prints
0x1.444p+99
but on Linux the same number is
0x0.A22p+99
That's much easier to deal with, because it's trivial to print the %A format.
Correctly-rounded %e, %f is much more difficult, unfortunately (you need some
simple bigint arithmetic).
|
Copyright © 1999-2021 by the D Language Foundation