[Cfp-interest 2694] Re: floating constants issue

[Jim Thomas]

> On Feb 9, 2023, at 7:38 AM, Vincent Lefevre <vincent at vinc17.net> wrote:
> 
> On 2023-02-02 14:44:48 -0800, Jim Thomas wrote:
>> 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.)
> 
> Warnings in the standard are better than nothing, but alone, they
> are not really satisfactory because in practice, most developers
> would not be aware of the issue, or may forget it. Warnings from
> compilers would be much better, but this would be possible only
> if the standard disallows (or at least discourages) such a form.
> 
> Another issue about constant rounding modes via pragmas is that
> they depend on a context that may not be very visible. This is
> even worse with macros. For instance, one may have in some header
> file:
> 
> #define CST 0.1
> 
> where the developer wants 0.1 rounded to nearest.
> 
> Another example: GCC has
> 
> #define __FLT_MIN__ 1.17549435082228750796873653722224568e-38F
> 
> so that one gets
> 
> $ printf "#include <float.h>\nFLT_MIN\n" | gcc -E -xc -
> [...]
> 1.17549435082228750796873653722224568e-38F
> 
> But the interpretation of this constant will not be correct
> in all constant rounding modes.

Right. There’s a similar problem with evaluation methods. If defined as a decimal constant, the constant must evaluate to the correct value under any of the possible evaluation methods it might be translated with. The way to avoid all these problems is to define the macros (for radix 2 or 16 types) as exact hexadecimal constants.

- 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)