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

[Jim Thomas]

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