I have a question about the compliance of the binary floating point library (libbfp754). In the documentation, a "Note" exists for all of the Quiet Computational Operations (abs, copy, copysign, negate) that states the following:
"When the input is a signaling NaN, two different outcomes are allowed by the standard. The operation could either signal invalid exception with quieted signaling NaN as output, or deliver signaling NaN as output without signaling any exception."
But I believe this is in contradiction with section 5.5.1 of the IEEE 754-2008 standard (not reprintable here), which explicitly states that these functions will only ever affect the sign bit and will not throw exceptions.
I have only seen the bfp754 library perform correctly (passing through a signaling NaN and not signaling an exception) on the two different systems I have compile and run my code on, but I need to know if the other behavior (returning a quiet NaN and signaling an exception) is actually allowed by the library, potentially making my code non-compliant on certain machines.
Link Copied
The numbers printed to the screen don't show the entire precision of the numbers being used in the code, which is a result of the default precision used in printf. The attached file displays more precision.
1.17549435e-38 is the min normal used
1.17549421e-38 is the max subnormal used
both yield the results I've shown on binaryconvert.com as well
Is there any response to either of these issues? Both issues keep the Intel IEEE754-2008 library from being compliant with the standard, with one even preventing it from representing all finite numbers from a hex string.
Issue #1: Shifting of hexadecimal bits in floating point significand
Issue #2: Incorrect exponent biasing/debiasing for subnormal numbers
Hi James,
Sorry for the long delay of response. I hope you are still interested in using our library. For the two issues you raised, I am not sure the behavior of the bfp754 library contradicts the IEEE 754 standard.
1) I don't think the standard specifies how to choose the leading "nonzero" character, except that it should be the most significant. Hence, I would assume all these representations are equally valid:
0x1.ffp+8
0x3.fep+7
0x7.fcp+6
0xf.f8p+5
2) I don't think the standard specifies that the exponent of the hex output of a subnormal number should be the bias.
For more complete information about compiler optimizations, see our Optimization Notice.