Exact floating-point number

[udaken]

Is there a way to accurately represent floating-point numbers in C#?
(similar to the hexadecimal floating point literals in the C language)

[CyrusNajmabadi]

All floating point numbers should have an exact and accurate representation in C#. These should roundtrip perfectly (any FP number should have an exact/accurate representation in C# that you can be certain will give you that exact FP value at runtime). This shoudl apply to both floats and doubles.

[CyrusNajmabadi]

You can see the code we have for this here: https://github.com/dotnet/roslyn/blob/main/src/Compilers/Core/Portable/RealParser.cs#L32

[tannergooding]

There’s some nuance here in that while the parser is IEEE 754 compliant that isn’t necessarily the same as all values being exact.

Not all decimal sequences can be represented exactly as float/double and so the value represented by double x = 0.3 is not exactly the number the user typed. That is, it is not 0.3.

Instead the value is parsed according to the IEEE 754 rules which means that it’s parsed to an exact value as if infinite precision and unbounded range were possible and then it is rounded to the nearest representable result, which is 0.299999999999999988897769753748434595763683319091796875

The IEEE 754 spec also defines a hexadecimal based format that allows representing values in a way that avoids any precision loss due to rounding. The value above would be 0x1.3333333333333p-2 which is just an hexadecimal based representation of the value

[tannergooding]

The hexadecimal format is supported by several other languages, and we have approved but not yet implemented support for the BCL.

It ends up making a lot of sense if you're familiar with the underlying format/etc. For example, the raw bit representation of the above value is 0x3FD3333333333333 and so the 1. means its a normal value (0. would be subnormal). The 3333333333333 is the stored significand and the 0x3FD is the stored biased exponent, so you subtract the bias (1023) to get the actual exponent of -2.

Thus, if you have 0x1.3333333333333p-2 and the standard floating-point representation of -1^sign * 2^exponent * (implicit + 2^(1-mantissaBitCount) * mantissa), you then get -1^0 * 2^(0x3FD - 1023) * (1 + 2^(1-53) * 0x3333333333333). Simplified, that is 1 * 2^-2 * (1 + 2^-52 * 900719925474099), which is exactly 0.299999999999999988897769753748434595763683319091796875

Or, put a bit more simply, the hexadecimal string format is 0x1.<mantissa>p<exponent>, and so for double is 2^exponent * (1 + 2^-52) * mantissa for all normal (non subnormal) numbers

[saucecontrol]

I would find hex float syntax useful for writing collection literals especially. In the same way that hex representation of integer literals can enhance readability in table form, a precise, (relatively) compact, and consistent length representation of floats would be easier on the eye when you're dealing with lots of them.

[TahirAhmadov]

Isn't the answer here the decimal type? Yes, it's not the same as float, but that's the thing - it gives up some things to deliver "exactness". Or did I misunderstand the question?

[tannergooding]

I took the question, particularly given the callout towards the hexadecimal string format, to be that they wanted a way to more succinctly represent floats/doubles exactly as strings.

0x1.3333333333333p-2 is much shorter than 0.299999999999999988897769753748434595763683319091796875 for example.

In the worst case, you'd be writing out 767 digits for the longest decimal string representing the exact value of a given double vs 0x1.<13-digits>p<4-digits> for the longest hexadecimal string.

[orthoxerox]

BitConverter.UInt64BitsToDouble() is my preferred solution when I need to ensure the bit pattern my double should have.

[udaken]

At the moment, it seems that the only way to try to describe the exact value is to manually convert the floating point number to hexadecimal, encode it to ulong and return it to BitConverter.UInt64BitsToDouble().