Clarify rounding rules for how floating point literal values are represented #67
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
docs/language-spec.md
Outdated
| too large to be represented, it is replaced with `inf` or `-inf` (depending on the sign | ||
| of the original value). | ||
| it is replaced with the nearest value that _can_ be represented by this format using | ||
| IEEE 754 round-to-even rules. When the value is too small to be represented, that nearest |
There was a problem hiding this comment.
Add a link: https://en.wikipedia.org/wiki/IEEE_754#Rounding_rules. I would also call it "ties to even", but they're interchangable.
Some further things to note here:
- If the nearest value is a denorm, the value is that denorm, not zero (explicitly exclude flush-denorm-to-zero). I have no idea whether Go
strconv.ParseFloathas this behavior if some knucklehead turns on hardware FTZ (AFAICT Go makes it reasonably hard to mess with fpenv stuff, at least). - Note that no floating-point literal can produce a NaN.
- We should note that the NaN that
nanproduces is unspecified beyond being a quiet NaN. (Should we specify that it's a positive NaN?) - Explicitly note that
-0.0produces negative zero (i.e., 0x80000000 for 32-bit floats). Go gets this wrong, for example. - Non-normatively note that virtually all atod implementations provided by programming languages implement these exact semantics (e.g., note that Go's
strconv.ParseFloatdoes this, but produces errors on overflow).
Elaborating on NaN: this is where it's parsed: https://github.com/protocolbuffers/protobuf/blob/2dde8f1cb56cc1035aa87f4ede08db0d6cbef37c/src/google/protobuf/compiler/parser.cc#L314. It calls C++ quiet_NaN, which is 0x7fc00000 or 0x7ff8000000000000 on every platform (see https://godbolt.org/z/dvo1En5sj). If we care about byte-for-byte compatibility of descriptors, it may be worth specifying this precise bit pattern...?
There was a problem hiding this comment.
Add a link: https://en.wikipedia.org/wiki/IEEE_754#Rounding_rules. I would also call it "ties to even", but they're interchangable.
I was following the wording in the Go language spec: https://go.dev/ref/spec#Representability
It does not provide a link and also calls it "round-to-even rules". But I'll update it so our spec is a little more user-friendly than Go's 😝
If the nearest value is a denorm, the value is that denorm, not zero
This seems to be getting into the weeds of IEEE754 representation. When the existing text says "too small to be represented", it's not meaning "too small to be represented in normalized form", so I think the existing text does adequately describe the behavior (and doesn't require the reader to be intimately familiar with nuances of IEEE754 representation).
Explicitly note that -0.0 produces negative zero (i.e., 0x80000000 for 32-bit floats). Go gets this wrong, for example.
I'm not sure it's worth specifying this. If Go gets it wrong, do we know that protoc and buf both get this right? Should it be necessary or expected that a compiler produce this exact value in this condition? This seems like over-specifying based on an implementation detail that is unlikely to be user-impacting.
If we care about byte-for-byte compatibility of descriptors
We do not. We already encode options differently than protoc by virtue of using Go's protobuf serialization implementation (and the fact that there is no canonical encoding of messages), and we also have known variances in source code info (for bugs I've filed against protoc). Also, the exact bit pattern is not consistent within protoc: default values are parsed differently than other values and IIRC this results in different bit patterns for -nan. So it would be kind of awful to actually include that inconsistency in the spec, as if it were an intentional part of the language and expected of other compilers. (I suppose we could also fix that bug in protoc and make it consistent -- in which case I assume the spec would be that -nan will have the sign bit set?)
But I think we can definitely clarify that nan bit-patterns will be quiet/non-signaling, even without suggesting an exact bit pattern that should be used.
There was a problem hiding this comment.
Another potential issue with specifying that -0.0 results in the floating point value -0.0 (with sign bit set) is that (I'm pretty sure anyway) this currently doesn't work with -0 (i.e. an int literal form is used). In this case, this is taken as an integer value zero and then converted to a floating point if necessary during type-checking.
There was a problem hiding this comment.
This sounds good to me. Re: -0, I think it's worth testing what protoc does, just to be sure. I suspect it actually does preserve it, given that it uses the textproto codepath where correctness actually matters, but I'm actually not certain. Float behavior is a place where a lot of languages' specs are pretty sloppy too (I would definitely consider Go's spec to be float-sloppy, personally).
No description provided.