[Cfp-interest 2616] Re: [SC22WG14.22918] CFP views on CA-N3073-006

[Hubert Tong]

On Mon, Jan 16, 2023 at 11:39 AM Jim Thomas <jaswthomas at sbcglobal.net>
wrote:

>
>
> 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>
> wrote:
>
>>
>>
>> On Jan 13, 2023, at 6:08 PM, Hubert Tong <
>> hubert.reinterpretcast at gmail.com> wrote:
>>
>> On Fri, Jan 13, 2023 at 8:13 PM Hubert Tong <
>> hubert.reinterpretcast at gmail.com> wrote:
>>
>>> On Wed, Jan 11, 2023 at 6:06 PM Joseph Myers <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.
>

All implementations I am familiar with (AIX and Linux on Power) will
require changes to macro definitions (Linux because of both reasons, and
AIX because of the second).


> Is there some known significant use of the macros that the implementation
> change (where required) would break?
>

I am not aware of any specific use that would break except that, generally,
this would be a change in behaviour where most deployed applications
already manage to operate with the existing behaviour. I would value input
on what macro changes may be most problematic. From the implementation
complexity perspective, I believe it would be the changes to
isnormal/fpclassify on AIX (with issubnormal being added). I also imagine
that the case where there are finite long double values with exponent
greater than LDBL_MAX_EXP (which is currently defined to match DBL_MAX_EXP
on both AIX and Linux on Power) is generally not expected by users of
LDBL_MAX_EXP (but I am not familiar with what people use LDBL_MAX_EXP for).

-- HT


>
> - 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
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20230116/663a0724/attachment.htm>