[cfp-interest 3893] Re: convertFrom and signaling NaNs

Thu Apr 16 22:31:58 PDT 2026

Thanks Rajan and Joshua,

§5.3.5.3.3 is what really tied it together for me. I always thought that
the term "value" refers to specification level 3 in ISO/IEC 60559
(Representations of floating-point data) rather than level 2
(Floating-point data). However, that's not the case in C, and the C wording
is arguably fine.

I've also updated the corresponding C++ issue at
https://github.com/cplusplus/CWG/issues/887

The realization that there is only one NaN value will be very helpful for
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2026/p3938r1.html,
which I probably need to revise under new assumptions.

Yours
Jan

On Fri, 17 Apr 2026 at 01:34, Joshua Cranmer <joshua.cranmer at intel.com>
wrote:

> (One side note: I'm not seeing Jan's messages to the list, only Rajan's
> replies, and the cfp-interest numbering marks Rajan's messages as
> consecutive. Are non-members' messages sent to some moderation queue?)
>
> So my take here is that everything is actually pretty clear if you
> understand how everything is supposed to fit together. But to figure that
> out, you have to very carefully read 2 different specifications (3, if
> you're looking at C++), and proceed to look in all of the wrong places of
> those specifications to figure out what anything even means.
>
> If we start in IEEE 754, Table 3.1 lays out 4 different levels of
> understanding floating-point arithmetic. Level 1 is extended real numbers,
> the mathematical system being approximated. Level 2 refers to
> floating-point data, where 0 is broken into -0 and +0, and a single NaN
> datum is added. Level 3 are floating-point representations, where finite
> numbers are broken into (sign, exponent, significand) and NaN is broken
> into a qNaN and sNaN. Level 4 is the final bit string layer (encodings).
> And then it gets confusing because, having introduced these layers, the
> standard then stops referring to them again, and you have to very carefully
> parse the wording to work out what level it's trying to apply semantics to.
> (In general, IEEE 754 is largely implicitly describing semantics in terms
> of floating-point representations [level 3], although there are some
> operations where the standard intends to precisely describe the encoding
> [level 4].)
>
> As for C, where we need to start is in fact section 5.3.5.3.3
> (Characteristics of floating-point types). Here we find the definition of
> floating-point numbers and some discussion on values. p10 starts by saying
> "A NaN is a value signifying Not-A-Number. A quiet NaN propagates..." (note
> that it says "a quiet NaN" and not "a quiet NaN value"). Again, here we
> start having to do some inference to figure out the intent. A careful
> reading of this section indicates that perhaps the best way to understand
> it is to map things to IEEE 754's definitions, mapping non-IEEE 754 types
> to equivalent IEEE 754 concepts as appropriate (e.g., NOTE 2).
>
> So how do we do the mapping? Again, careful reading illustrates that there
> is a difference between "value" and "representation." The C
> "representation" corresponds to level 4 in IEEE 754. The C "value" term is
> trickier to pin down, but from 5.3.5.3.4 (Characteristics of decimal
> floating-point type) and the discussion of quantum exponents (particularly
> p9) lets you infer that "value" corresponds to IEEE 754 level 2: a value is
> a floating-point datum.
>
> It is arguable that you could map "value" to IEEE 754's level 3 (which
> distinguishes a qNaN from a sNaN "floating-point representation",
> annoyingly the same word that C uses for something different). But arguing
> that NaNs having different payloads are distinct values is pretty clearly
> wrong. See e.g., EXAMPLE 5 in 6.7.2, where the code has a comment
> explicitly saying "quiet NaNs in real floating types are considered the
> same value, regardless of payloads," or footnote 453 in F.10.14.
>
> On 4/16/2026 17:33, RAJAN BHAKTA wrote:
>
> Hi Jan,
>
> I was giving a specific case of value, but the general case I believe
> holds: The value of a NaN (signaling or otherwise) is a NaN (not a number).
> The signaling or quiet aspects are not a part of the value. i.e. Section
> 6.3.2.5 “Real Floating Types" is concerned with value preservation (e.g.,
> 3.14 remains 3.14, infinity remains infinity, NaN remains NaN), not with
> preserving the signaling/quiet distinction. So the “precise meaning of an
> object” is that it’s a NaN. Essentially this is similar to how various
> non-canonical representations can all represent the same value, including
> ones that provide additional information outside of the value.
>
> I can see we disagree on this part, and hence it may make sense to make a
> change to the standard to make it clear/explicit.
>
> Regards,
>
> *Rajan Bhakta*
> CFP
>
>
> *From: *Jan Schultke <janschultke at googlemail.com>
> <janschultke at googlemail.com>
> *Date: *Thursday, April 16, 2026 at 2:36 PM
> *To: *RAJAN BHAKTA <rbhakta at us.ibm.com> <rbhakta at us.ibm.com>
> *Cc: *cfp-interest at oakapple.net <cfp-interest at oakapple.net>
> <cfp-interest at oakapple.net>
> *Subject: *[EXTERNAL] Re: convertFrom and signaling NaNs
>
> This Message Is From an Untrusted Sender
> You have not previously corresponded with this sender.
> Report Suspicious
> <https://us-phishalarm-ewt.proofpoint.com/EWT/v1/AdhS1Rd-!-XFVHHo80mE1PTx5QApOe0MNwyUrt8VlzhzyXnGn4Y8_94nA7bR9HcQ1oehNyiAE3Gw7otUUz_hDMhyC04yy7R0Sd-8A4pRdkMHubMqr580uF4xrI1ioZLjfiA$>
>
>
> Hi,
>
> How to handle issues for C (WG14) are given at
> https://www.open-std.org/jtc1/sc22/wg14/issues/
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.open-2Dstd.org_jtc1_sc22_wg14_issues_&d=DwMFaQ&c=BSDicqBQBDjDI9RkVyTcHQ&r=XTIN0AwPKAf2bIKNxlzdeqggAytE5h-JEusWpx9MXwc&m=Q07maytVJxXWrqyVGB6sEg51yjqEWSF2wU7ccFJXUClAAvfsz6thR6JHnA7eKU3N&s=tNvLT0zA5tU8F2RRX6RwWm3s91cp_o_OPU-YGZEcT84&e=>.
> Essentially you need to email the issue to c-issues at open-std.org.
>
>
> Thanks, I can do that, but first let's make sure we're on the same page.
>
> For this particular issue, I believe the value for the SNaN is the payload
> and that is unchanged. The operation still raises “invalid” as expected
> from any operation (including conversion) other than the very small set
> that explicitly do not do so (ex. The issignaling macro).
>
>
> Firstly, ISO/IEC 60559 merely recommends that NaN payloads are
> propagated. §6.2.3 is full of "should". It would be extremely surprising if
> the C requirement EVEN for implementations that don't conform to Annex F
> was stricter than ISO/IEC 60559. That can't be right, but the wording says
> the value is unchanged, and you're reading "value" as synonymous with NaN
> payload.
>
> Secondly, I don't know why you would read that as being synonymous here.
> "value" as defined in §3.24 is the "precise meaning of the contents of an
> object when interpreted as having a specific type". It's a C construct
> derived from contents of an object, so when the C wording requires that a
> "value" is unchanged, I'm reading that as an sNaN not turning into a qNaN
> since those are two different values. However, the underlying hardware
> operation does turn sNaNs into qNaNs, and so does the convertFormat
> operation in ISO/IEC 60559, so I'm not finding any way to read the C
> wording as non-defective.
>
> Anyway, I'm not really an expert, so I'd be happy if you could elaborate
> on this before I go and report to someone else :)
>
>
> Yours
> Jan
>
> _______________________________________________
> cfp-interest mailing listcfp-interest at oakapple.nethttp://mailman.oakapple.net/mailman/listinfo/cfp-interest
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20260417/803bf968/attachment-0001.htm>