[Cfp-interest 2298] Re: Usual arithmetic conversions for long double and _FLoat64

[David Olsen]

>> How specifically would this help?

It keeps things more consistent when porting between conforming implementations that have different formats for long double.  The code can rely on the result type being long double everywhere (unless porting to an unusual non-conforming compiler that has IEEE 64-bit but long double is smaller than 64 bits, in which case this will be the least of their concerns).

It also matches my conceptual ranking of the types.  _Float64 is conceptually the same size as double (because on conforming implementations they have to be the same format), and long double is always conceptually bigger than double (even if they happen to be the same format).  That means long double is conceptually bigger than _Float64, even if they happen to be the same format.  This is the reasoning that I used for C++ when writing P1467.

>> There's still the issue of long double arithmetic possibly being less robust than _Float64.

I think consistency among conforming implementations should be valued more than improving the experience on non-conforming implementations.  We should of course try for both, but in this case I think they are in conflict.

>> Are you suggesting that there be a special rule that applies only to long double + _Float64 when they have the same formats?

Yes.  There would be a special rule that, when the sets of values are equivalent, the result type of long double + _Float64 would be long double.  I can't think of a better way to specify it given how the arithmetic conversion rules are defined.

I'm not going to stress about this.  I can't think of any way that code that will compile as both C and C++ can tell the difference.

(My apologies for not replying in time for this morning's teleconference.  If that means I missed my chance to advocate for this change, oh well.)



From: Cfp-interest <cfp-interest-bounces at oakapple.net> On Behalf Of Jim Thomas
Sent: Sunday, October 24, 2021 2:26 PM
To: CFP <cfp-interest at ucbtest.org>
Subject: [Cfp-interest 2243] Re: Usual arithmetic conversions for long double and _FLoat64

On Oct 17, 2021, at 9:20 PM, David Olsen <dolsen at nvidia.com<mailto:dolsen at nvidia.com>> wrote:

On an implementation where double, long double, and _Float64 all have the same format of IEEE 64-bit, what is the result type of an operation with operands of long double and _Float64?  My reading of the usual arithmetic conversions in section X.4.2 if N2601<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg14%2Fwww%2Fdocs%2Fn2601.pdf&data=04%7C01%7Cdolsen%40nvidia.com%7Cc331e055f85c4b6059b508d99735a5ee%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637707079520388731%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=1yAzogjKkzKVMVB793tXoHLcabo2i9F1KOcdYb9E6NA%3D&reserved=0> is that the result type is _Float64, because interchange floating types are preferred over standard floating types when the two types have the same sets of values.  Is my interpretation correct?

Yes.


I am working on modifying the C++ floating-point proposal P1467 so that the usual arithmetic conversion rules match those in N2601 and C23, as was requested in the joint SG22/CFP meeting.  I am having trouble with this one situation.

On implementations where long double is bigger than double, long double + _Float64 -> long double.  I think the usual arithmetic conversion rules should be consistent so that long double + _Float64 -> long double all the time, even when long double has the same set of values as _Float64.  This will help users when porting code between implementations that have different representations for long double.

How specifically would this help? There's still the issue of long double arithmetic possibly being less robust than _Float64.


Is it possible to tweak the usual arithmetic conversion rules in C23 to make this change?

Are you suggesting that there be a special rule that applies only to long double + _Float64 when they have the same formats?



(I believe that long double + _Float64 is the only combination of standard and interchange floating types where the result type can change between conforming implementations.  I guess long double + _Float128 -> long double if long double is bigger than _Float128, but I don't think any such implementations exist.)

If long double were double-double then long double and _Float128 would be unordered.

If all possible C implementation are considered I think there are several exceptions. For example, long double could be narrower than _Float64. (This is not true with strict conformance to the C annex for IEEE floating types.)

- Jim Thomas


(I have no problem with double + _Float64 -> _Float64.  That makes sense, and I have changed the C++ proposal to do that.  It is only long double + _Float64 that I have an issue with.)

  - David Olsen


_______________________________________________
Cfp-interest mailing list
Cfp-interest at oakapple.net<mailto:Cfp-interest at oakapple.net>
http://mailman.oakapple.net/mailman/listinfo/cfp-interest<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmailman.oakapple.net%2Fmailman%2Flistinfo%2Fcfp-interest&data=04%7C01%7Cdolsen%40nvidia.com%7Cc331e055f85c4b6059b508d99735a5ee%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637707079520398729%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Szlmr0i2H0%2B6jXdVqrtOpRi7P96xGb7V9s9nEmR5tzA%3D&reserved=0>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20211123/9752212a/attachment.htm>