[Cfp-interest 2386] Re: WG14 2022-01 Meeting summary for CFP

[Jim Thomas]

> On Feb 14, 2022, at 6:34 PM, Vincent Lefevre <vincent at vinc17.net> wrote:
> 
> On 2022-02-13 10:11:27 -0800, Jim Thomas wrote:
>> On Feb 9, 2022, at 9:19 AM, Vincent Lefevre <vincent at vinc17.net> wrote:
>>> "Whether and in what cases subnormal numbers are treated as zeros is
>>> implementation defined."
>>> 
>>> Do you mean that in this case, if x is a subnormal number, then
>>> x == 0 may return true and/or x may be printed as 0?
>> 
>> Yes.
> 
> Something else that is not clear is whether this is still allowed
> when Annex F is claimed to be supported, i.e. whether this overrides
> the bindings specified in Annex F.

If the implementation declares support for Annex F it is saying it treats subnormals according to the annex and hence does not treat them as zeros. It’s not a matter of overriding, but a way of meeting the general requirement (to define whether and when subnormals are treated as zeros).

> 
>>> Note that the only requirement about equality seems to be given in
>>> 6.2.6.1p4:
>>> 
>>> Two values (other than NaNs) with the same object representation
>>> compare equal, but values that compare equal may have different
>>> object representations.
>>> 
>>> And one knows that two different objects may compare equal, e.g.
>>> +0.0 and -0.0 when FP zero is signed (thus they are really different
>>> objects, not the same object with different representations).
>>> 
>>> But I would have thought that the value of a FP number is the real
>>> value implied by the model.
>> 
>> Right. But the model representation is an abstraction that doesn’t
>> necessarily match the bit pattern. A C object representation
>> containing the bit pattern of a 754 subnormal need not represent a
>> subnormal number in the C model. A C implementation (not supporting
>> Annex F) may regard all 754 subnormals as zeros.
> 
> The bit pattern is off-topic in 5.2.4.2.2 (this would be a bit like
> if, in IEEE 754, you were talking about Level 4 in a context about
> Level 2 only).

Agreed.

> And if Annex F is not supported, then "754 subnormals"
> is meaningless.

“754 subnormals” was a shortened reference to the "bit pattern of a 754 subnormal” in the preceding sentence. At any rate, I believe I misunderstood what you were getting at. Yes, a reasonable expectation would be, as you say,  "that the value of a FP number is the real value implied by the model”, so a subnormal number in the model might be expected to behave like a non-zero number. The specification noted above about treating subnormals as zeros in implementation-defined cases is a concession to existing practice. I suppose whether this concession is for the good is debatable.

> 
>>> BTW, if there is a signed infinity, the C standard does not seem to
>>> require that -infinity < x and x < +infinity for any x that represents
>>> a real value. Or what am I missing?
>> 
>> C 6.5.8 says "Each of the operators < (less than), > (greater than),
>> <= (less than or equal to), and >= (greater than or equal to) shall
>> yield 1 if the specified relation is true and 0 if it is false. This
>> applies to signed infinities as well as to any other numbers.
> 
> These relations are mathematically defined over the real numbers.
> But infinities are an addition of the C standard (assuming Annex F
> is not supported).

Hmm. Signed infinities are recognized in the C standard as an optional extension to the minimal set of values of floating types. The relations (<, etc.) are mathematically defined over the extended real numbers (adding signed infinities). Has any implementation claimed to have signed infinities that don't satisfy -inf < x < +inf for finite x? I suppose one could — infinities are extensions to the standard, not optional fully specified features (except for Annex F implementations).

- 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