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

[Damian McGuckin]

Vincent, Jim,

On Mon, 1 Nov 2021, Jim Thomas 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.

I thought the original HUGE_VAL first appeared in System V Rel 3 Unix. It 
was the largest finite value of the type. Never infinity.

But then, over time, on systems which supported infinities, it become the 
same as infinity on so many systems, I started assuming it was the same as
INFINITY (on systems which supported infinity).

That also means that

 	nextUp(HUGE_VAL) == HUGE_VAL, .... if INFINITY is supported

 	nextUp(HUGE_VAL) == HUGE_VAL, .... if INFINITY is NOT supported

 	nextDown(-HUGE_VAL) == -HUGE_VAL, .... if INFINITY is supported

 	nextUp(-HUGE_VAL) == -HUGE_VAL, .... if INFINITY is NOT supported

so it is consistent and not some exception for nextUp (or nextDown if the 
value is negative).

> None of these are a problem for IEC 60559 implementations and I don?t 
> know if they are for any significant implementations.

I am curious how nextUpf()/nextDownf() work on a Cell CPU. Rajan?

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

That definitely needs to be clear and any words about this which are 
unclear need to change.

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

I agree that seemingly different explanations in multiple places is messy. 
I assume that ensuring consistencyt in explanations is NOT a new proposal.
I like the words "clarification of intent".  The world would be a better 
place if that occurred a lot more!

Stay safe - Damian

Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW 2037
Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here
Views & opinions here are mine and not those of any past or present employer