[basic.fundamental] Exhaustively list what values can be represented by floating-point types #8554
Conversation
eisenwave
force-pushed
the
acknowledge-zero-sign
branch
from
87188f1 to
852d447
Compare
eisenwave
force-pushed
the
acknowledge-zero-sign
branch
2 times, most recently
from
2001f63 to
20426f9
Compare
source/basic.tex
Outdated
| A floating-point type shall at least represent a subset of rational numbers | ||
| called \defnadjx{finite}{values}{value}. | ||
| Depending on the implementation-defined value representation for the type, | ||
| it may additionally represent the finite value negative zero, |
There was a problem hiding this comment.
Talking about negative zero as distinct from the other zero implies that the other one is naturally positive, but mathematically that's not true. It's true for IEEE floats but not mathematics. It might be better to talk about zero being signed, rather than saying there can also be negative zero.
I haven't come up with a good way to phrase that though.
There was a problem hiding this comment.
Maybe say something like there are finite values, and maybe infinities, and NaNs, and they might all have a sign, including zero.
There was a problem hiding this comment.
N5014 already uses "negative zero" 9 times, and C has some mentions of it too. It doesn't make much mathematical sense, but I really don't see how we could avoid saying "negative zero" when that's the established term of the last 30 years; we use that anywhere else.
We also mention "negative NaN values" in [cmp.alg].
cplusplus/CWG#817 clarifies that neither negative NaNs nor negative zero are negative values. I can see how this is all a bit paradoxical and unhelpful, but I wouldn't be comfortable with avoiding this terminology only in [basic.fundamental].
There was a problem hiding this comment.
My objection isn't to mentioning negative zero at all, only in this context of something definition-like where you're mentioning it in addition to some other value, which either implies we have "zero and negative zero" or that it's just obvious that the other one is positive zero. But neither of those things is so obviously true that it doesn't need clarifying. A floating-point type might just have a zero value (or several equivalent zero values), without any sign, or it might have signed zeros, in which case it has both positive zero and negative zero. So I think introducing negative zero should be in the context of zero being (possibly, depending on the implementation) signed. Because that implies a positive zero too, not just "real zero and some negative zero thing".
There was a problem hiding this comment.
I.e. the existence of negative zero in the IEEE formats is a direct consequence of zero (and all other values) having a sign bit.
I've just discovered that C23 now requires a sign bit for all values:
https://cigix.me/c23#5.2.5.3.3.p8
C17 didn't:
https://cigix.me/c17#5.2.4.2.2.p4
There was a problem hiding this comment.
I don't think it makes sense to normatively refer to positive zero, because a format that doesn't have a signed zero doesn't have positive zero, it just has zero.
Now if we follow C23 and require signed zeros, that isn't a problem - but that would be a normative change.
There was a problem hiding this comment.
Ok, I think I figured out a way to phrase it. The new wording says that any one of those values listed may have two distinct negative/positive versions.
By using the word "distinct", it's still clear that those aren't two identical values that have a quasi-padding sign bit, but that they are technically distinct values.
There was a problem hiding this comment.
I.e. the existence of negative zero in the IEEE formats is a direct consequence of zero (and all other values) having a sign bit.
I've just discovered that C23 now requires a sign bit for all values: https://cigix.me/c23#5.2.5.3.3.p8
C17 didn't: https://cigix.me/c17#5.2.4.2.2.p4
I misread the new C23 wording, it still allows unsigned zero. "Floating types shall be able to represent signed zeros or an unsigned zero"
There was a problem hiding this comment.
... and I assume we don't change that in any way? The currently proposed paragraph seems to be fine then.
eisenwave
force-pushed
the
acknowledge-zero-sign
branch
from
20426f9 to
0dcac5f
Compare
…by floating-point types
eisenwave
force-pushed
the
acknowledge-zero-sign
branch
from
0dcac5f to
17545cb
Compare
jensmaurer
added
cwg
|
I hope it's clear we're not adding normative stuff ("shall") using an editorial issue. |
3 participants
This is branching off from cplusplus/CWG#814 (comment)
There are various mentions of NaNs, positive and negative zeros, infinities, etc. scattered throughout the standard. We do a bad job of comprehensively listing these possibilities in one place.
It's also not obvious whether we consider floating-point types to require having a positive and negative zero, positive and/or negative infinity, NaN values, and whatnot. This is really difficult to figure out.
My understanding of the wording is that floating-point types are only guaranteed to represent some rational numbers; anything else, such as NaNs, infinities, negative zeros, etc. may or may not exist, based on the representation of
floatchosen by the implementation.