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

[Rajan Bhakta]

Unfortunately I don't have access to the Cell library or compiler anymore
so I can't check what next* do. I do know HUGE_VAL does give infinity for
double and long double, but FLT_MAX for float.

Regards,

Rajan Bhakta
z/OS XL C/C++ Compiler Technical Architect
ISO C Standards Representative (Canada, USA), PL22.11 Chair
C/C++ Compiler Development
rbhakta at us.ibm.com

IBM



From:	"Damian McGuckin" <damianm at esi.com.au>
To:	"CFP" <cfp-interest at ucbtest.org>
Date:	11/01/2021 07:35 PM
Subject:	[EXTERNAL] [Cfp-interest 2253] Re: nextup/nextdown and HUGE_VAL
            definition
Sent by:	"Cfp-interest" <cfp-interest-bounces at oakapple.net>




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
_______________________________________________
Cfp-interest mailing list
Cfp-interest at oakapple.net
http://mailman.oakapple.net/mailman/listinfo/cfp-interest



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20211102/cfaffb8a/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20211102/cfaffb8a/attachment.gif>