[Cfp-interest 2280] Re: nextup/nextdown and HUGE_VAL definition

[Jim Thomas]

So, 

7.12 #5, where the HUGE_VAL macros are introduced, does not explicitly specify a value for them.

7.12.1 #5, 7.22.1.5 #10, and 7.29.4.1.1 #10 implicitly specify the value of he HUGE_VAL macros as the value returned when a library function result overflows under the default rounding mode.

Annex F specifies the value of the HUGE_VAL macros to be infinity.

Some users belief the HUGE_VAL macros give the largest number in the type (infinity or the value of type_MAX).

Problem 1

The meaning of the HUGE_VAL macros is unclear. Is it the overflow result (for the default rounding mode), or is it the maximum number in the type. Examples of cases where the difference in meanings would matter:

a. The default rounding (for library functions) is toward zero, but the maximum number in the type is infinity.

b. Some double-double implementations might reasonably prefer to return a reduced-precision number for an overflow result (as explicitly allowed by the most recent CFP draft proposal on overflow) and that number would vary from cases to case, depending on the severity of overflow. However, the implicit specification for the macro values implies that overflow results are fixed under the default rounding mode.

Suggested fix

In 7.12.1, specify that the value of a HUGE_VAL macro is the maximum value returned by llbrary functions when a floating result of the type overflows under the default rounding mode, either the maximum finite number in the type or positive or unsigned infinity. 

Problem 2

The specification for the nextup and nextdown functions refer to the HUGE_VAL macros, though the intention of the functions — to step through representable values — is not related to overflow or rounding mode. 

Suggested fix

Reword the specification of the nextup and nextdown functions to not refer to the HUGE_VAL macros, along the lines Vincent suggested. For example,

Replace 

	nextup(HUGE_VAL) is HUGE_VAL,

with 

	If x is the maximum number in the type, nextup(x) is x.

- Jim Thomas

> On Nov 1, 2021, at 4:30 PM, Jim Thomas <jaswthomas at sbcglobal.net> wrote:
> 
> I was surprised to see that C doesn’t directly define the value of HUGE_VAL. I had thought the HUGE_VAL macros gave the largest value in their type, but ... The library (in math.h and the string conversion functions) specifies them as the value to be returned if (positive) overflow occurs, and default rounding is in effect. And online references say HUGE_VAL macros give the value returned on overflow. This means an implementation that had infinities but rounded toward zero by default would define the HUGE_VAL macro to be the maximum finite value in the type. 
> 
> The library specification requires the overflow result to be the value of the HUGE_VAL macro, with the appropriate sign, which would be problematic for (or disallow) default rounding up or down. It might also be a problem if the type had unsigned infinity, depending on rounding. 
> 
> None of these are a problem for IEC 60559 implementations and I don’t know if they are for any significant implementations.
> 
> As for nextup/nextdown, I think they just step through representable values and were never intended to be tied to overflow or rounding direction. This argues for a change like you suggest. We might be able to present it as something less than a new proposal. A clarification of intent?
> 
> - Jim Thomas
> 
>> On Oct 29, 2021, at 4:37 AM, Vincent Lefevre <vincent at vinc17.net> wrote:
>> 
>> The current C2x draft (N2731) says:
>> 
>> 7.12.11.5 The nextup functions
>> 
>> The nextup functions determine the next representable value, in
>> the type of the function, greater than x. [...] nextup(HUGE_VAL)
>> is HUGE_VAL.
>> 
>> (with symmetric text for nextdown).
>> 
>> Shouldn't the first sentence add something like "or equal to x
>> if x is the maximum value (of the type)"?
>> 
>> I suppose that it is the intent of "nextup(HUGE_VAL) is HUGE_VAL.",
>> but this is not completely clear. Note in particular that this could
>> be interpreted as required only for HUGE_VAL (i.e. for double, but
>> not necessarily for nextupf(HUGE_VALF) and nextupl(HUGE_VALL)).
>> Moreover, if this means that HUGE_VAL is the maximum value for the
>> double type, the other parts of the standard are written like this
>> were not necessarily the case. Or does this mean that HUGE_VAL is
>> an exception to the general rule for nextup? (I hope not.)
>> 
>> So, IMHO, it would be simpler to add "or equal to x if x is the
>> maximum value (of the type)" and remove the sentence on HUGE_VAL
>> (which is incorrect if HUGE_VAL is not the maximum value).
>> 
>> If HUGE_VAL, HUGE_VALF and HUGE_VALL are expected to be the maximum
>> values of the type, then the standard should be modified everywhere
>> it suggests that this isn't necessarily the case. (Note that for the
>> decimal types, the associated macros expand to positive infinity, so
>> that they are OK.) This includes:
>> 
>> 7.12 Mathematics <math.h>
>> [...]
>> 5   The macro
>>           HUGE_VAL
>>     expands to a positive double constant expression, not
>>     necessarily representable as a float. [...]
>> 
>> 245) HUGE_VAL, HUGE_VALF, and HUGE_VALL can be positive infinities
>> in an implementation that supports infinities.
>> 
>> i.e. it currently doesn't require it to be the maximum value, even
>> on implementations that support infinities. Thus this would need to
>> be changed.
>> 
>> And also
>> 
>> F.10 Mathematics <math.h> and <tgmath.h>
>> [...]
>> 2   The Standard C macro HUGE_VAL and its float and long double
>>     analogs, HUGE_VALF and HUGE_VALL, expand to expressions whose
>>     values are positive infinities.
>> 
>> could be removed as part of the new general definition.
>> 
>> The question is whether this would break existing implementations.
>> 
>> -- 
>> 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)
>> _______________________________________________
>> Cfp-interest mailing list
>> Cfp-interest at oakapple.net
>> http://mailman.oakapple.net/mailman/listinfo/cfp-interest
> 
> 
> _______________________________________________
> Cfp-interest mailing list
> Cfp-interest at oakapple.net
> http://mailman.oakapple.net/mailman/listinfo/cfp-interest