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