On 10/26/21 6:01 AM, Vincent Lefevre wrote:
> In article <sk1pd2$5e3$3@dont-email.me>,
> James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>
>> On 10/9/21 4:17 PM, Vincent Lefevre wrote:
....
>>> If this is defined behavior, where is the result of an overflow
>>> defined by the standard? (I can see only 7.12.1p5, but this is
>>> for math functions; here, this is a constant that overflows.)
>
>> "For decimal floating constants, and also for hexadecimal floating
>> constants when FLT_RADIX is not a power of 2, the result is either
>> the nearest representable value, or the larger or smaller representable
>> value immediately adjacent to the nearest representable value, chosen in
>> an implementation-defined manner.
>> For hexadecimal floating constants when FLT_RADIX is a power of 2, the
>> result is correctly rounded." (6.4.4.2p3)
>
>> In the case of overflow, for a type that cannot represent infinity,
>> there is only one "nearest representable value", which is DBL_MAX.
>
> 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. If the
constant is greater than DBL_MAX, the "nearest representable value" is
always DBL_MAX. The next smaller representable value is
nextafter(DBL_MAX, 0). If infinity is representable, the "larger ...
representable value" is infinity; otherwise, there is no "larger
representable value", and one of the other two must be chosen.

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

In article <sl9ba7$ees$1@dont-email.me>,
James Kuyper <jameskuyper@alumni.caltech.edu> wrote:

> No definition by the standard is needed; the conventional mathematical
> definitions of "nearest" are sufficient. If infinity is representable,

Meanwhile in the real world, programmers don't have to abide by
single standard. I believe all floating point hardware
manufactured today uses IEEE arithmetic. So programmers have to
deal with both standards as the same time, ISO C and IEEE. And
other applicable simultaneous standards and APIs.

--
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. @
'I desire mercy, not sacrifice.' /|\
Discordia: not just a religion but also a parody. This post / \
I am an Andrea Doria sockpuppet. insults Islam. Mohammed

On Tuesday, October 26, 2021 at 1:37:20 PM UTC-4, Siri Cruise wrote:
> In article <sl9ba7$ees$1...@dont-email.me>,
> James Kuyper <james...@alumni.caltech.edu> wrote:

Note: I mistakenly posted that message here before posting it in it's
intended newsgroup, comp.std.c. I canceled that message with both
of the news servers that I have accounts on, but such cancellation
requests are seldom are honored by other news servers, which is
presumably why you were able to see it here.

> > No definition by the standard is needed; the conventional mathematical
> > definitions of "nearest" are sufficient. If infinity is representable,
>
> Meanwhile in the real world, programmers don't have to abide by
> single standard. I believe all floating point hardware
> manufactured today uses IEEE arithmetic. So programmers have to
> deal with both standards as the same time, ISO C and IEEE. And
> other applicable simultaneous standards and APIs.

I believe that there are still non-IEEE floating point formats in use; I had
to deal with one such format just a few years ago. But I'm willing to
concede that most programmers will never have to deal with anything
other than IEEE floating point format. What is your point?

If the C standard specified anything about the conversion from floating
point constants to floating point values that was inconsistent with the
requirements of IEEE decimal string to value conversions, that would
simply mean that an implementation of C could not perform such
conversions by making use of IEEE floating point math - it would have
to add some code to implement those differences. However, to the best
of my knowledge, there are no such inconsistencies. Do you know of
any?

If __STDC_IEC_559__ is pre#defined by the implementation with a value
of 1, then the specifications of Annex F apply, which mostly correspond
to IEC 60559 (==IEEE 754). In that case, conversion of decimal and
hexadecimal constants is supposed to implement the IEC 60559
operations convertFromDecimalCharacter and
convertFromHexCharacter, respectively.

IEC 60559 identifies at least one, and usually two different possible
values for any such conversion, with the correct choice depending upon
what the current rounding direction is. The C standard is more lenient -
it identifies at least two, and usually three, permitted values for such a
conversion. It only requires that the value be chosen to correctly
implement the default rounding direction for hexadecimal constants
when FLT_RADIX is a power of 2. However, the values allowed by IEC
60559 are, in all cases, a subset of the ones allowed by the C standard,
so IEC 60559 is always compatible with C's requirements.

The original message I was responding to, which is not quoted above,
was about formats which do not support infinities, which excludes IEC
60559 formats.

On Wednesday, 27 October 2021 at 01:37:20 UTC+8, Siri Cruise wrote:
> In article <sl9ba7$ees$1...@dont-email.me>,
> James Kuyper <james...@alumni.caltech.edu> wrote:
>
> > No definition by the standard is needed; the conventional mathematical
> > definitions of "nearest" are sufficient. If infinity is representable,
>

Some one understand ∞+1 ≠ ∞ (like I do)
Some one believe ∞+1 = ∞ (like many do)
From the latter, inf+x==inf+y can be deduced.
I.e. no any finite number is closer than others to infinity,
I.e. all finite numbers are equally close to infinity(inf).

> Meanwhile in the real world, programmers don't have to abide by
> single standard. I believe all floating point hardware
> manufactured today uses IEEE arithmetic. So programmers have to
> deal with both standards as the same time, ISO C and IEEE. And
> other applicable simultaneous standards and APIs.
>
> --
> :-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. @
> 'I desire mercy, not sacrifice.' /|\
> Discordia: not just a religion but also a parody. This post / \
> I am an Andrea Doria sockpuppet. insults Islam. Mohammed