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

Thu Apr 16 16:33:49 PDT 2026

(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>
> *Date: *Thursday, April 16, 2026 at 2:36 PM
> *To: *RAJAN BHAKTA <rbhakta at us.ibm.com>
> *Cc: *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 list
> cfp-interest at oakapple.net
> http://mailman.oakapple.net/mailman/listinfo/cfp-interest

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20260416/a5e538da/attachment-0001.htm>