[Cfp-interest 2615] Re: [SC22WG14.22900] CFP views on CA-N3073-006

[Jim Thomas]

> On Jan 14, 2023, at 4:13 PM, Hubert Tong <hubert.reinterpretcast at gmail.com> wrote:
> 
> On Sat, Jan 14, 2023 at 4:16 PM Jim Thomas <jaswthomas at sbcglobal.net <mailto:jaswthomas at sbcglobal.net>> wrote:
>> 
>> 
>>> On Jan 13, 2023, at 6:08 PM, Hubert Tong <hubert.reinterpretcast at gmail.com <mailto:hubert.reinterpretcast at gmail.com>> wrote:
>>> 
>>> On Fri, Jan 13, 2023 at 8:13 PM Hubert Tong <hubert.reinterpretcast at gmail.com <mailto:hubert.reinterpretcast at gmail.com>> wrote:
>>>> On Wed, Jan 11, 2023 at 6:06 PM Joseph Myers <joseph at codesourcery.com <mailto:joseph at codesourcery.com>> wrote:
>>>>> 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.)
>>>> 
>>>> Note: There is also new information about the behaviour of isnormal and LDBL_MIN.
>>>> 
>>>> Hi Joseph,
>>>> 
>>>> I am interested in knowing what value, in your experience, the value of LDBL_EPSILON for double-double was replaced with. The CD wording would require LDBL_EPSILON to be DBL_EPSILON (without playing games with model parameters other than "p" anyway).
>> 
>> The CD does not require LDBL_EPSION to be DBL_EPSILON (when long double is double-double). If some part implies that, that’s an accidental mistake.
>> 
>> The updated specification in the CD is intended to build on the historical understanding of the floating-point model, to remove inconsistencies, to clarify, and especially to allow types with double-double formats to conform. There are different ways a double-double format can be fitted to the model. Key is the implementation’s choice of values for the model parameters p, emax, and emin. The requirement is that all normalized floating-point numbers in the model with the chosen parameters be representable in the type. Since the CD allows additional finite numbers inside and outside the range of normalized numbers, the implementation has considerable latitude for choosing its model parameters. The choice of p = 106 (mentioned below) is ok, provided emax and emin are chosen so that all p-precision numbers in that range are representable. 
> 
> That's what I meant by "playing games" with other model parameters. It is true that the Linux on Power implementation already chooses a emin that works with 106, but emax is not similarly modified. A possible reason is that there is an explicit concept of subnormal numbers in the C standard, but there is no explicit concept of "supernormal" numbers (exponent too large for full precision; not that any number beyond DBL_MAX that is representable as a double-double with a correctly-rounded most-significant double actually suffers from having less precision -- it is just that some numbers with double's emax as the exponent would overflow).
> 
> In any case, the primary objection is the lack of strong rationale for modifying the values in existing implementations (again, among other "problems", the value used for "p" is not consistent between macros for Linux on Power and, on both AIX and Linux on Power, the value for "emax" does not support a value of "p" greater than that of "double").

Again, the following are my thoughts. CFP will discuss this thread at its meeting this week.

If I understand correctly, the objection is not to the CD specification except that it requires some current implementations to change macro values. The proposed change to address this introduces new macro equivalent to the CD ones and loosens the requirements for the existing macros to allow implementations to keep whatever values they currently have. 

The rationale for modifying the current macros (as opposed to creating new ones) is that those are the macros in use. The last Proposed Technical Corrigendum (April 2017, too late for C18) for the DR #467 included a change to clarify that a type must be able to represent all normalized numbers, i.e. all numbers with a given precision (p) within a given exponent range (emin through emax). This property is important for users, and, I believe, has been generally assumed. For example, users might reasonably expect that

#include <float.h>
#ifdef LDBL_MANT_DIG >= 105
long double x = 0x1.1234567890123456789012345Fp0L;
#endif

would store the exact value of its initializer in x.

The change proposed in CA-N3073-006 qualifies the definition of the *_MANT_DIG (and other) macros with  “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”. This change would invalidate the code, and the general assumption about the macros.

The change proposed in CA-N3073-006 also introduces new macros that are equivalent to the ones in the CD. This would be a cost to users in needing to understand more specification, the differences between old and new macros, and which ones they should use. I’d expect almost all users would want the ones in the CD and (with the proposed change) they would need to modify their code to get them.

For the CD, an implementation would need to change its macro definitions only if (1) the values are not currently consistent with respect to some fixed p, emax, and emin, or (2) the implementation doesn’t support the fundamental property above for its chosen p, emax, and emin. Is there some known significant use of the macros that the implementation change (where required) would break? 

- Jim Thomas

> 
> I will take the opportunity to note that "normal" as defined by "isnormal" (and probably "fpclassify") is not the same as "normalized", and I am in favour of leaving it that way to avoid confusing programs with new classifications.
>  
>> 
>> A stricter specification didn’t seem desirable. There is no standard (official or de facto) for double-double arithmetic and implementations vary.
> 
> I am not asking for a stricter specification, I am asking for the strictness presented in the CD to be applied to a parallel set of macros.
> 
> -- HT
>  
>> 
>> - Jim Thomas
>> 
>>>> 
>>>> For reference, the "p" value used on AIX for LDBL_EPSILON and LDBL_MANT_DIG is 106 (i.e., 53 + 53). Representation of values with that precision is trivially achievable with double-double except at extreme magnitudes (both small and large). On Linux, the "p" value for LDBL_MANT_DIG is also 106, and LDBL_MIN on Linux accounts for the range where the magnitude is too small [note 1] (the value on AIX does not). However, the "p" value used for LDBL_EPSILON on Linux is 1075 (which is the result of using the old difference from 1 to least value greater than 1 definition).
>>>> 
>>>> Note 1: isnormal on Linux also accounts for the range where the magnitude is too small to provide 106 bits of precision. I am having some trouble ascertaining the AIX behaviour.
>>>> 
>>>> I am not sure how the macros are currently used in ways that benefit from the current definitions used on the affected platforms. but it seems that "if it is not broken, don't fix it" applies. In other words, decades of deployment experience should have some weight. Additionally, I don't think it is a stretch that, with the new macro values (at least for LDBL_MANT_DIG), programs may mistakenly assume that `double` and `long double` are interchangeable for the affected platforms.
>>>> 
>>>> Although implementations may choose to apply the new values only when compiling for C23, this does not prevent multi-platform applications moving to C23 for other reasons from being inadvertently exposed on Power platforms to this change. Deliberate adoption by users of new macros is the best indication of user intent.
>>>> 
>>>> In light of the new information regarding LDBL_MIN and isnormal, I believe the proposed resolution may need to be expanded with similar provisions for LDBL_MODEL_MIN, is_model_normal, and fp_model_classify.
>>> 
>>> LDBL_MIN_EXP on Linux is in a similar situation as LDBL_MIN. I guess the approach of introducing new macros with the model-mandated values may just end up creating a full set of such macros.
>>>  
>>>> 
>>>> I hope this information is useful for the discussion.
>>>> 
>>>> Sincerely,
>>>> 
>>>> 
>>>> Hubert Tong
>>>>  
>>>>> 
>>>>> (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 <mailto:joseph at codesourcery.com>
>> 

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