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

[Jim Thomas]

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.

-	Jim Thomas


> Begin forwarded message:
> 
> From: Joseph Myers <joseph at codesourcery.com>
> Subject: [SC22WG14.22874] CFP views on CA-N3073-006
> Date: January 11, 2023 at 3:05:52 PM PST
> To: <sc22wg14 at open-std.org>
> 
> N3073 (updated Canada comments) includes a new comment CA-N3073-006, which 
> I think the CFP group should provide views on.  (Personally I don't think 
> new macros are needed there; in particular, any uses of LDBL_EPSILON for 
> double-double tended in my experience to need to override the value, to 
> replace one with the old semantics with one with (or close to) the new 
> (N2326) semantics, and indeed the change to *_EPSILON in N2326 is arguably 
> a defect fix for part of the issue originally reported in DR#467.)
> 
> (The other new floating-point-related comments in N3073 shouldn't need CFP 
> comments: CA-N3073-003 is a duplicate of GB-016, while CA-N3073-002 and 
> CA-N3073-004 are routine editorial comments.)
> 
> -- 
> Joseph S. Myers
> joseph at codesourcery.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20230113/4c09a8f2/attachment.htm>