[Cfp-interest 2612] Re: [SC22WG14.22896] CFP views on CA-N3073-006

[Hubert Tong]

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").

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/20230114/0962af07/attachment-0001.htm>