Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
proposal: Go 2: hexadecimal floats #29008
What version of Go are you using (
Someone pointed out that I haven't explained why I don't think Float64FromBits solves this problem.
In this case, obviously decimal is fine, but I am pretty convinced that a hex float literal is way more legible than Float64FromBits for that value.
So that's a good counterargument to what I said, but I don't feel persuaded, making me think I didn't actually say anything that communicated what I'm looking for. A better way of expressing it might be: I don't want to have to think about the zeroes at all. They're a weird artifact of the normalized representation. Say I want to have a floating-point constant. if I write it as a hex float, I get a 100% predictable float constant that can be used for both float32 and float64, assuming they have sufficient precision, and I know exactly what it means in either of them, and don't have to guess about or think about rounding errors. If I write it in Float##FromBits, I have to have two forms of it because they're different lengths.
Hex floats offer a convenient way to express mantissa values with reliable precision. They are much more human-reader friendly than IEEE's normalized mantissa values, and getting the exponent in decimal, but still in powers of 2, turns out to map nicely onto what's actually happening.
When people first proposed this for C, I was... sort of skeptical. Why would you want floats in hex? That's not how they work! That's not how anything works! But there were enough floating point people on the committee to get it adopted, and I didn't really have an objection, I just didn't see the point. But as I've spent time trying to decipher float values, it's become increasingly clear to me that, while dealing with the whole float as a large unsigned integer certainly works, it's not really easy to read. I can't look at a
It's a lot easier for me to understand "p-3" than "0x3FC". YMMV.
EDIT: I was wrong, though, the 4 isn't the sign bit, the exponent is stored unsigned using a bias of +127. This goes back to my basic assertion that this is not a programmer-friendly way to view float values.
This was referenced
Jan 17, 2019
We've posted a combined proposal for #19308, #12711, #28493, and #29008 at golang.org/design/19308-number-literals. It includes hex floats as suggested in this issue. (I could have sworn there was an earlier issue proposing hex floats, but I can't find it.)
Note that this will be the first proposal to follow the process outlined in the Go 2 here we come! blog post: we will have everything ready to go and checked in at the start of the Go 1.13 cycle (Feb 1), we will spend the next three months using those features and soliciting feedback based on actual usage, and then at the start of the release freeze (May 1), we will make the "launch decision" about whether to include the work in Go 1.13 or not.
Thanks for your feedback and all your help improving Go.