Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #82165

Re: contradiction about the INFINITY macro

Show all headers | View raw

On 10/28/21 5:38 AM, Vincent Lefevre wrote:
> In article <sl9bqb$hf5$2@dont-email.me>,
>   James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
> 
>> On 10/26/21 6:01 AM, Vincent Lefevre wrote:
>>> OK, but I was asking "where is the result of an overflow defined by
>>> the standard?" I don't see the word "overflow" in the above spec.
> 
>> Overflow occurs when a floating constant is created whose value is
>> greater than DBL_MAX or less than -DBL_MAX. Despite the fact that the
>> above description does not explicitly mention the word "overflow", it's
>> perfectly clear what that description means when overflow occurs.
> 
> Why "perfectly clear"??? This is even inconsistent with 7.12.1p5
> of N2596, which says:

7.12.1p5 describes the math library, not the handling of floating point
constants. While the C standard does recommended that "The
translation-time conversion of floating constants should match the
execution-time conversion of character strings by library functions,
such as strtod , given matching inputs suitable for both conversions,
the same result format, and default execution-time rounding."
(6.4.4.2p11), it does not actually require such a match. Therefore, if
there is any inconsistency  it would not be problematic.

>   A floating result overflows if the magnitude (absolute value)
>   of the mathematical result is finite but so large that the
>   mathematical result cannot be represented without extraordinary
>   roundoff error in an object of the specified type.

7.12.1p5 goes on to say that "If a floating result overflows and default
rounding is in effect, then the function returns the value of the macro
HUGE_VAL ...".
As cited above, the standard recommends, but does not require, the use
of default execution-time rounding mode for floating point constants.
HUGE_VAL is only required to be positive (7.12p6) - it could be as small
as DBL_MIN. However, on implementations that support infinities, it is
allowed to be a positive infinity (footnote 245), and when
__STDC_IEC_559__ is pre#defined by the implementation, it's required to
be positive infinity (F10p2). Even if it isn't positive infinity, it is
allowed to be DBL_MAX. DBL_MAX and positive infinity are two of the
three options allowed by 6.4.4.2p4 for constants larger than DBL_MAX, in
which case there's no conflict.
If HUGE_VAL is not one of those three values, then 6.4.4.2p4 still
applies, but 7.12.1p5 need not apply, since a match to the behavior of
strtod() is only recommended, not required..

> If you have a mathematical value (exact value) much larger than
> DBL_MAX and that rounds to DBL_MAX (e.g. with round-toward-zero),
> there should be an overflow, despite the fact that the FP result
> is not greater than DBL_MAX (since it is equal to DBL_MAX).

Agreed. As a result, the overflow exception should be signaled. However,
the C standard mandates that "Floating constants are converted to
internal format as if at translation-time. The conversion of a floating
constant shall not raise an exceptional condition or a floating-point
exception at execution time." (6.4.4.2p8). If an implementation chooses
to do the conversion at translation-time, the exception would be raised
only within the compiler, which has no obligation to do anything with
it. The implementation could generate a diagnostic, but such a constant
is not, in itself, justification for rejecting the program.

Therefore, if an implementation chooses to defer actual conversion until
run-time, it's required to produce the same results, which means it must
clear that overflow exception before turning control over to the user code.

> Moreover, with the above definition, it is DBL_NORM_MAX that is
> more likely taken into account, not DBL_MAX.

According to 5.2.4.2.2p19, DBL_MAX is the maximum representable finite
floating point value, while  DBL_NORM_MAX is the maximum normalized
number. 6.4.4.2p4 refers only to representable values, saying nothing
about normalization. Neither 7.12.5p1 nor 7.12p6 say anything to require
that the value be normalized. Therefore, as far as I can see, DBL_MAX is
the relevant value.

>>> Note also that in case of overflow, "the nearest representable value"
>>> is not defined.
> 
>> No definition by the standard is needed; the conventional mathematical
>> definitions of "nearest" are sufficient. If infinity is representable,
>> DBL_MAX is always nearer to any finite value than infinity is.
>> Regardless of whether infinity is representable, any finite value
>> greater than DBL_MAX is closer to DBL_MAX than it is to any other
>> representable value.
> 
> The issue is that this may easily be confused with the result
> obtained in the FE_TONEAREST rounding mode with the IEEE 754 rules
> (where, for instance, 2*DBL_MAX rounds to +Inf, not to DBL_MAX,
> despite the fact that 2*DBL_MAX is closer to DBL_MAX than to +Inf).

Yes, and DBL_MAX and +Inf are two of the three values permitted by
6.4.4.2p4, so I don't see any conflict there. As far as I can see, the
value required by IEEE 754 is always one of the three values permitted
by 6.4.4.2p4, so there's never a conflict. Are you aware of any?

For hexadecimal floating point constants on systems with FLT_RADIX a
power of 2, 6.4.4.2p4 only allows one value - the one that is correctly
rounded - but that's precisely the same value that IEEE 754 requires.

Back to comp.lang.c++ | Previous | Next | Find similar | Unroll thread

Thread

Re: contradiction about the INFINITY macro James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-28 11:22 -0400

csiph-web