Add support for hex floating point literals

[The-Futurist]

A double is a binary floating point data format and there are are valid binary values that cannot be expressed using the existing decimal literal notation.

So what about adding support for hex floating point literals? (which can always losslessly be converted to binary float/double).

For example this value (which can readily be written to a 64 bit value that comprises a double:

0x1.f44abd5aa7ca4p+5

cannot be expressed in decimal the best we can do is:

62.5364939768271845828... (these digits go on forever)

No matter what we write in decimal form, we can never get this value into the double : 0x1.f44abd5aa7ca4p+5

[SSM240]

For example this value (which can readily be written to a 64 bit value that comprises a double:

0x1.f44abd5aa7ca4p+5

cannot be expressed in decimal the best we can do is:

62.5364939768271845828... (these digits go on forever)

I don't think this is actually true. If all valid finite floats are binary fractions, then they all have terminating decimal representations (specifically, I believe the criteria for a terminating decimal is that the denominator's only prime factors are 2 and/or 5).

In the case of your specific example, according to this site it should be 62.536493976827188134848256595432758331298828125. And of course for a C# program you don't need that many digits, since doubles have much less precision than this:

[The-Futurist]

How would one write that smallest value today in C#?

float.Epsilon would be my guess. Is that it? I think I prefer seeing that over the specific example of 0x1.0p-126.

I hear you on the fact that other languages decided it was worth supporting. That on its own does support your case, but as a sole motivation, it doesn't tend to get things moving. Different niches are represented in different ratios between languages. Knowing that people frequently face concrete scenarios in today's C# is a great motivator.

The hex notation is part of the IEEE-754 standard and has been adopted by many programming languages, I don't see adding this to C# as being particularly contentious, it's a pretty basic suggestion, simpler than the existing conversion from decimal literals to single or double.

There's a simple correspondence between a hex float literal and the binary representation used within the 64 bit datum.

[CyrusNajmabadi]

it's a pretty basic suggestion

That is something that certainly is better than the opposite :)

However, the goal we have when doing language features is how much value they provide as a whole. As per a statement above, if htis is going to only be used a tiny handful of times, then this is a massive investment for little payoff. Personally, i would be fairly deeply concerned around the validation of this, as FP is absolutely a place where there have been bugs over the years.

[The-Futurist]

However, the goal we have when doing language features is how much value they provide as a whole. As per a statement above, if htis is going to only be used a tiny handful of times, then this is a massive investment for little payoff. Personally, i would be fairly deeply concerned around the validation of this, as FP is absolutely a place where there have been bugs over the years.

Well you're the experts, but one can expect bugs when converting decimals float strings into the binary used by the standard, there's a huge scope for edge cases and rounding and so on. But the binary float strings are a bit for bit representation of the bits in the 64-bit datum, I won't say this is trivial but I'd be surprised if it was truly seen as "massive investment".

(The hex notation is intended as a means of lossless serializing single/double format data)

[CyrusNajmabadi]

But the binary float strings are a bit for bit representation of the bits in the 64-bit datum

As someone who just introduced a lexing bug in roslyn that took 6+ months to track down, i can tell you that it is easy to get stuff wrong, and it's painful to find and fix :)

[The-Futurist]

But the binary float strings are a bit for bit representation of the bits in the 64-bit datum

As someone who just introduced a lexing bug in roslyn that took 6+ months to track down, i can tell you that it is easy to get stuff wrong, and it's painful to find and fix :)

You should blog about that, if a team of gurus at a huge company like MS, took six months to find a bug, there are lessons to be learned by all!

[jilles-sg]

Now that parsing has been fixed to return the nearest number and formatting has been fixed to return roundtrippable strings from .ToString() and .ToString("G") (see e.g. https://devblogs.microsoft.com/dotnet/floating-point-parsing-and-formatting-improvements-in-net-core-3-0/?hide_banner=true ), there is much less reason for hexadecimal floating point literals.

[HaloFour]

See: #7277

[The-Futurist]

Yes, as he points out: