[Cfp-interest 2724] Re: WG14 IEEE 754-C binding meeting minutes 2023/01/31

[Jim Thomas]

> On Mar 1, 2023, at 6:00 AM, Vincent Lefevre <vincent at vinc17.net> wrote:
> 
> On 2023-02-27 15:52:20 -0800, Jim Thomas wrote:
>> Good point. Would a definition requiring just inclusion work? That
>> would be: type A is wider than type B iff the values of A are a
>> superset of the values of B. Then double-double would be wider than
>> binary64, even though binary64 has the greater exponent range (for
>> full precision of the types). Are there places where use of the
>> wider type terminology depends on wider exponent range?
> 
> I think that the inclusion would work. But the definition needs to be
> unambiguous. For instance, it needs to be clear whether the case where
> one format has unsigned zeros while the other format has signed zeros
> is accepted, in particular, whether { 0 } is included in { +0, −0 }.
> Ditto for NaN and their payloads: does the inclusion of the payloads
> matter?

Note that 6.2.5 #12 says “… The set of values of the type float is a subset of the set of values of the type double; the set of values of the type double is a subset of the set of values of the type long double.” That goes back at least to C99. Just pointing out, this is not a recently introduced issue. I think the determination of inclusion in the cases of signed zeros and different NaNs has been left to the implementation. That seems right, at least for non-IEC 60559 implementations, whose treatment of signed zeros and NaNs is so loosely specified by C. If we compare { 0 } and { +0, −0 } for purposes of determining value inclusion, it’s still just about values and not about subtle behavior in the arithmetic (without conformance to IEC 60559). 

For IEC 60559 formats, unsigned zeros are not an issue. Since Annex F allows long double to be a non-IEC 60559 format, we might consider an Annex F requirement for long double to have signed zeros. I wouldn’t expect that to affect any actual implementations.

I think all quiet NaN representations should be regarded as one value, for purposes of determining value inclusion. The meaning of NaN payloads is left almost entirely to the implementation. F.10.13#1 says "The payload is intended for implementation-defined diagnostic information about the NaN.” 

We might consider adding a note or footnote in F.10.13 saying: for purposes of determining value inclusion (as in 6.2.5 and 7.12), quiet NaN representations can be regarded as having the same value, regardless of payloads. This should be paired with an earlier suggested change for 7.12, to replace the words about wider types with ones about value subsets as in 6.2.5 (which I think should be done anyway).

- Jim Thomas

> 

> -- 
> Vincent Lefèvre <vincent at vinc17.net> - Web: <https://www.vinc17.net/>
> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
> _______________________________________________
> Cfp-interest mailing list
> Cfp-interest at oakapple.net
> http://mailman.oakapple.net/mailman/listinfo/cfp-interest