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

[Jim Thomas]

> On Feb 9, 2022, at 9:19 AM, Vincent Lefevre <vincent at vinc17.net> wrote:
> 
> On 2022-02-09 10:59:06 -0500, Rajan Bhakta wrote:
>> 5.8.1 Tydeman, *_HAS_SUBNORM==0 implies what? [N 2797] (the green part
>> only, which was skipped at the previous meeting)
>>  Fred: Since the standard does not define what happens whether subnormals
>> are flushed or not, we added this text to define it.
>>  Seacord: Adding positive zero to positive zero is different from +0 to
>> -0.
>>  Fred: Totally different. Existing hardware has the user being able to
>> handle subnormal operands vs results. 4 different modes.
>>  Seacord: That has nothing to do with 754? Just hardware?
>>  Fred: Operations, not operands in 754. It is optional and CFP is not
>> asking C to support it.
>>  Joseph: The 754 is different from what HW does. It is complicated and
>> depends on the rounding mode.
>>  Fred: Doesn't matter for this case. This mainly applies to ARM chips and
>> what's in your cell phone.
>> 
>>  Straw poll: Does WG14 want N2797 (the green text) in C23?
>>    15/0/2. Consensus. Goes into C23.
> 
> For clarification...
> 
> "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.
> 
> 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.
> 
> 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.
> 
> And if there is an unsigned infinity, may one have infinity < x and
> x < infinity for any x that represents a real value? (If such a case,
> the < relation would not be a strict order relation on the values,
> but this does not seem to be required by the standard.)

A C implementation with an unsigned infinity would need to determine how it compared with other numbers. The unsigned projective infinity that was proposed for the first IEEE 754 standard compared unordered with all finite numbers.

Is anyone aware of a commercial C implementation with an unsigned infinity?

- 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