[Cfp-interest 2682] Re: floating constants issue

Thu Feb 2 14:44:48 PST 2023

> On Feb 2, 2023, at 1:04 PM, Hans Boehm <boehm at acm.org> wrote:
> 
> I think many people are also surprised by the fact, pointed out by Vincent here, and already mentioned in a footnote, that -0.1 is effectively rounded in the opposite direction of what was specified, something you can't tell without carefully reading in the standard that negation is not part of the constant's matissa (though it clearly is for the exponent).

This is a long standing and well know problem. There are attempts to minimize the problem and warn about it. See (in N3054):

6.4.4.2 #12 NOTE 1 (In a previous message I mistakenly referred to 6.4.4.3.)
7.24.1.5 #4 footnote 355
7.24.1.6 #4 (Since the strtodN functions are new, we were able to require negation before rounding.)
F.5 #5 (For implementations that support Annex F "IEC 60559 floating-point arithmetic”, the strtod functions are required to negate before rounding.)

- Jim Thomas

> I'm becoming more convinced that ideally explicit rounding should operate on a different type that requires rounding direction to be explicitly specified for every operation. The syntax will be ugly, but users might actually get it right. I'm also unclear as to whether explicit rounding modes are used enough to motivate implementers to actually invest effort here.
> 
> The WG21/SG6 discussion of my rounding mode paper is scheduled for Thursday evening PST, next week.
> 
> Hans
> 
> On Thu, Feb 2, 2023 at 10:20 AM Jim Thomas <jaswthomas at sbcglobal.net <mailto:jaswthomas at sbcglobal.net>> wrote:
>> Some more thoughts about floating constants …
>> 
>> Email messages
>> [Cfp-interest 2673] Re: floating constants issue   Vincent Lefevre
>> [Cfp-interest 2676] Re: floating constants issue   Jim Thomas
>> [Cfp-interest 2669] Re: floating constants issue   Hans Boehm
>> [Cfp-interest 2677] Re: floating constants issue   Jim Thomas
>> 
>> discuss issues following from the specification that constant rounding modes affect floating constants. 
>> 
>> Rationale for the current specification is that it provides a way to control the rounding direction of floating constants. Without it, to get the value for a particular rounding of a decimal floating constant, one might need to replace the constant with an exact hexadecimal constant with the value of the rounded decimal constant, or one might be able to use an execution time operation (e.g. strtod) in place of the constant, provided the context didn’t require a constant. The rounding direction pragmas couldn’t be used to determine bounds without such extra attention for constants. 
>> 
>> The problem Vincent pointed out in the example in 7.6.2  NOTE 1 shows constant rounding modes can’t be completely implemented with dynamic rounding controls, because constants are affected by constant modes but not by dynamic modes. The note can be fixed by replacing the first sentence
>> 
>> Constant rounding modes could be implemented using dynamic rounding modes as illustrated in the following example: ...
>> 
>> with
>> 
>> Constant rounding modes could be implemented using dynamic rounding modes as illustrated in the following example, except that this method does not interpret inexact floating constants according to the constant rounding mode as required. 
>> 
>> The note will still serve to illustrate the relationship between constant and dynamic rounding modes. 
>> 
>> Hans showed a possibly surprising implication of identical forms having different values because of constant rounding modes. Yes, constant rounding modes (as specified) need to be used with the awareness that inexact floating constants might get different values. Finding floating constants not affected by constant rounding modes might be surprising too.
>> 
>> - Jim Thomas
>> 
>>> On Feb 1, 2023, at 9:38 AM, Jim Thomas <jaswthomas at sbcglobal.net <mailto:jaswthomas at sbcglobal.net>> wrote:
>>> 
>>> 
>>> 
>>>> On Jan 31, 2023, at 8:14 AM, Hans Boehm <boehm at acm.org <mailto:boehm at acm.org>> wrote:
>>>> 
>>>> I think this means that the same integer constant expression can now evaluate to different integers depending on the rounding mode. 
>>> 
>>> Yes, I think that’s right.
>>> 
>>>> Thus
>>>> 
>>>> int a[1 + (int)0.99999999999999999999999999999999999)]; may not be type compatible with itself, if it occurs in different rounding mode contexts.
>>> 
>>>> 
>>>> I'm not enough of a language lawyer and C compiler expert to determine whether this can be made to work. But I suspect the reason for the original rule was that somebody thought it couldn't.
>>> 
>>> I’d guess the original rule was to disallow the translator from giving different results because of internal reasons unrelated to the semantics of the source code.
>>> 
>>> - Jim Thomas
>>> 
>>>> 
>>>> Hans
>>>> 
>>>> On Tue, Jan 31, 2023 at 7:40 AM Jim Thomas <jaswthomas at sbcglobal.net <mailto:jaswthomas at sbcglobal.net>> wrote:
>>>>> 
>>>>> 
>>>>>> On Jan 30, 2023, at 5:51 PM, Vincent Lefevre <vincent at vinc17.net <mailto:vincent at vinc17.net>> wrote:
>>>>>> 
>>>>>> On 2023-01-30 15:19:52 -0800, Jim Thomas wrote:
>>>>>>> 6.4.4.2 #8 says:
>>>>>>> 
>>>>>>> All floating constants of the same source form 83) shall convert to the same internal format with the same value.
>>>>>>> 
>>>>>>> With the FENV_ROUND and FENV_DEC_ROUND pragmas this is no longer true. For example, 7.6.2 #4 for FENV_ROUND says "Floating constants (6.4.4.2) of a standard floating type that occur in the scope of a constant rounding mode shall be interpreted according to that mode."
>>>>>>> 
>>>>>>> This was pointed out in a recent email which I was unable to find. Thanks to the sender.
>>>>>> 
>>>>>> I posted the remark about 6.4.4.2 #8 in Cfp-interest 2634:
>>>>>>  http://mailman.oakapple.net/pipermail/cfp-interest/2023-January/002648.html
>>>>>> 
>>>>>> But I hadn't noticed the issue with FENV_ROUND.
>>>>>> 
>>>>>>> A fix would be to replace the sentence with something like:
>>>>>>> 
>>>>>>> All floating constants of the same source form shall convert to the same internal format. All floating constants of the same source form that are subject to the same translation-time rounding direction (either the default or a rounding direction set by an FENV_ROUND or FENV_DEC_ROUND pragma) shall convert to the same internal format with the same value.
>>>>>>> 
>>>>>>> or
>>>>>>> 
>>>>>>> All floating constants of the same source form shall convert to the same internal format and, provided they are subject to the same translation-time rounding direction (either the default or a rounding direction set by an FENV_ROUND or FENV_DEC_ROUND pragma), to the same value.
>>>>>> 
>>>>>> Both are unclear. What if it is set to FE_DYNAMIC?
>>>>> 
>>>>> Maybe
>>>>> 
>>>>> All floating constants of the same source form shall convert to the same internal format and, provided they are subject to the same translation-time rounding direction (either the default or a constant rounding mode other that FE_DYNAMIC set by an FENV_ROUND or FENV_DEC_ROUND pragma), to the same value.
>>>>> 
>>>>> But that would suggest that same-form floating constants could have different values under FE_DYNAMIC. Setting to FE_DYNAMIC should not affect the translation time conversion of floating constants in that they would still get default translation-time rounding.
>>>>> 
>>>>>> 
>>>>>> BTW, is there a way to restore the static rounding mode when
>>>>>> outside external declarations? This would be important if one
>>>>>> wants to use this pragma in a header file.
>>>>> 
>>>>> It can be “restored" to FE_DYNAMIC which serves as a “default”.
>>>>> 
>>>>> - Jim Thomas
>>>>>> 
>>>>>> -- 
>>>>>> Vincent Lefèvre <vincent at vinc17.net <mailto: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 <mailto:Cfp-interest at oakapple.net>
>>>>>> http://mailman.oakapple.net/mailman/listinfo/cfp-interest
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> Cfp-interest mailing list
>>>>> Cfp-interest at oakapple.net <mailto:Cfp-interest at oakapple.net>
>>>>> http://mailman.oakapple.net/mailman/listinfo/cfp-interest
>>> 
>>> _______________________________________________
>>> Cfp-interest mailing list
>>> Cfp-interest at oakapple.net <mailto:Cfp-interest at oakapple.net>
>>> http://mailman.oakapple.net/mailman/listinfo/cfp-interest
>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20230202/9b292ec2/attachment-0001.htm>