Printing shortest decimal form of floating point number with Mir

9il ilyayaroshenko at gmail.com
Mon Jan 4 12:11:04 UTC 2021


On Monday, 4 January 2021 at 05:58:09 UTC, Walter Bright wrote:
> On 1/3/2021 8:37 PM, 9il wrote:
>> I didn't believe it when I got a similar answer about IEEE 
>> floating-point numbers: D doesn't pertinent to be IEEE 754 
>> compatible language and the extended precision bug is declared 
>> to be a language feature.
>
> The "extended precision bug" is how all x87 code works, C to 
> C++ to Java. The reason is simple - to remove the problem 
> requires all intermediate results to be written to memory and 
> read back in, which is a terrible performance problem. Early 
> Java implementations did this write/read, and were forced to 
> change it.

Since C99 the default x87 behavior is precise.
https://cpp.godbolt.org/z/7sa8dP

For older C versions GCC provides -fexcess-precision=standard 
flag.

Java is going to restore the original behavior.
https://bugs.openjdk.java.net/browse/JDK-8175916

C# has an option to control virtual machine behavior
https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/control87-controlfp-control87-2?view=msvc-160

Finally, x87 is a deprecated architecture. It likely will be 
supported for a few decades. From the business's point of view, 
no one expects the best performance from the code compiled for 
x87. Instead of speed, numeric correctness is much more important 
here. I wouldn't explain why extended precision is inaccurate, 
because Kahan and Darcy already wrote an 80-page essay about it:

"How Java’s Floating-Point Hurts Everyone Everywhere"
https://people.eecs.berkeley.edu/~wkahan/JAVAhurt.pdf




More information about the Digitalmars-d-announce mailing list