[Cfp-interest 2606] Re: Fwd: [SC22WG14.22874] CFP views on CA-N3073-006

[Fred J. Tydeman]

On Fri, 13 Jan 2023 13:48:13 -0800 Jim Thomas wrote:
>
>The subject line refers to the comment:
>
>CA-N3073-006
>5.2.4.2.2 te 
>Comments
>The deployment impact of making a change to
>the floating-point model by clarifying that model
>parameters are to be chosen such that all
>normalized floating-point numbers are
>representable is unknown. Both AIX and Linux on
>Power use values of "p" for "double-double" that
>does not match the new definition in the CD.
>Proposed change
>For float, double, and long double: Add new
>*_MODEL_MANT_DIG and *_MODEL_EPSILON
>macros with the definitions of the *_MANT_DIG
>and *_EPSILON macros from the CD.
>For float, double, and long double: Modify the
>definitions of *_MANT_DIG and *_EPSILON by
>adding "in relation to implementation-defined
>model parameters not subject to the restriction
>that the floating type is able to represent all
>normalized floating-point numbers".
>
>Following are my initial thoughts about CA-N3073-006. They are intended as input to CFP discussion of the comment. 
>Ideally, we'll be able to arrive at a CFP response by email without needing the teleconference tentatively scheduled for 
>Wednesday, January 18.
>
>The proposed change to the existing *_MANT_DIG and *_EPSILON macros, i.e. adding "in relation to 
>implementation-defined model parameters not subject to the restriction that the floating type is able to represent all 
>normalized floating-point numbers" would seem to undermine the very notion of precision as a property of the type. What 
>would the type precision p mean? What use could be made of the macros (with the proposed changes)?
>
>How do the AIX and Linux implementations referred to in the comment currently define the macros?
>
>In C18, 5.2.4.2.2 #4, "In addition to normalized floating-point numbers (f1 > 0 if x  0), floating types may be able to contain 
>other kinds of floating-point numbers " is problematic grammatically and could be taken to mean floating types do 
>contain the normalized numbers. Users might well have assumed that normalized model numbers are represented in the 
>type (which has been generally true) and used the relevant macros accordingly. The change proposed in the comment 
>would indicate that most users should switch to the new macros. A better approach would seem to be for implementations 
>mentioned in the comment to introduce their own macros suitable for their interpretation of the parameters.
>
>If it is deemed necessary to allow unrepresentable normalized numbers, then the following might be considered:
>
>Change the first sentence of 5.2.4.2.2 #8:
>
>Floating types shall be able to represent signed zeros or an unsigned zero and all normalized floating-point numbers.
>
>to:
>
>Floating types shall be able to represent signed zeros or an unsigned zero and should be able to represent all 
>normalized floating-point numbers. Whether the type can represent all normalized floating-point numbers is 
>implementation defined.

I am against such a change.

To me, a normalized number is one where any of the 'p' digits may take on any value and still be a normalized number
(except most significant digit cannot be zero).


---
Fred J. Tydeman        Tydeman Consulting
tydeman at tybor.com      Testing, numerics, programming
+1 (702) 608-6093      Vice-chair of INCITS/C (ANSI "C")
Sample C17+FPCE tests: http://www.tybor.com
Savers sleep well, investors eat well, spenders work forever.