[cfp-interest 3656] Re: C2Y's canonicalise() in AnnexF - F.10.9.7

[Jim Thomas]

> On Oct 14, 2025, at 10:00 AM, Jim Thomas <jaswthomas at sbcglobal.net> wrote:
> 
> 
> 
>> On Oct 13, 2025, at 5:22 PM, Damian McGuckin <damianm at esi.com.au> wrote:
>> 
>> On Mon, 13 Oct 2025, Jim Thomas wrote:
>> 
>>> Unlike most math functions, canonicalize is a function at the bit-representation (bit-string) level. At this level, signaling NaNs exist (for Annex F implementations), whether or not the implementation supports them. I think the Annex F specification for canonicalize needs to be explicit about quiet and signaling NaNs.
>> 
>> Thanks for the guidance.
>> 
>> Could it say (using the stricter syntax in the discussion paper):
>> 
>> F.10.9.7#1 The canonicalize functions
>> 
>> - canonicalize (cx, x) returns a quiet NaN in the object pointed to by cx
>> and raises the "invalid" floating-point exception when the object pointed
>> to by x is a signaling NaN .
>> - canonicalize (cx, x) returns a quiet NaN in the object pointed to by cx
>> when the object pointed to by x is a quiet NaN .
>> 
>> NOTE: The first sentence of the existing Paragraph#1 appears to be a rewording of parts of Section 7 and as such, does not belong in Annex F. The last two sentences of the existing Paragraph#1 are phrased totally unlike all of the existing content of Annex F. The above rectifies that.

Not a rewording. Clause 7 does not require the function to be successful: simply returning 1 would be a valid implementation. F.10.9.7 requires the function to store a canonical representation, per ISO/IEC 60559, and return 0.

The suggestion above omits the recommendation that signaling NaN input result in a quiet NaN "which should be the canonical version of that
signaling NaN made quiet”.

>> 
>> DROP: footnote 451).

The footnote seems problematic because it doesn’t apply to all canonicalize functions.

- Jim Thomas

>> 
>> Thanks - Damian
>