[Cfp-interest] 754 compatibility action item

[Ian McIntosh]

Does "y finite not zero or infinite" mean "y finite not (zero or infinite)"
or "y finite (not zero) or infinite"?  Would "y finite not zero and not
infinite" be clearer and have the correct meaning?

- Ian McIntosh          IBM Canada Lab         Compiler Back End Support
and Development




From:	Jim Thomas <jaswthomas at sbcglobal.net>
To:	David Hough Cfp <cfp-interest at oakapple.net>
Cc:	CFP <cfp-interest at ucbtest.org>
Date:	2018-04-09 06:07 PM
Subject:	Re: [Cfp-interest] 754 compatibility action item
Sent by:	cfp-interest-bounces at oakapple.net





> On Apr 7, 2018, at 2:48 PM, David Hough CFP <pcfp at oakapple.net> wrote:
>
>
>> David: Look into the IEEE binding differences to see if they are real=20
> issues (from Fred's email on 2018/02/18).
>
>
> min/max and payload are more complex and I will try to look at those
> separately.
>
> Here's my CONCLUSIONS on the simple cases.
> Is this what you were looking for?:
>
>
> 18661-1 versus 754
>
> 18661-1 has
>  remainder(x, +/-inf) returns x for x not infinite. [Allows x=NaN]
> 754 has
>  remainder(x, inf) is x for finite x. (5.3.1)
>  remainder(x, inf) is exact for finite normal x. (6.1)
>  remainder(subnormal, inf) signals underflow. (6.1)
> CONCLUSION:
> 18661-1 needs to encompass these cases:
> remainder(x, +/-inf) returns x for finite x, and if x is subnormal,
> raises the "underflow" exception.

The 754 remainder operation signals underflow, but does not raise the
underflow flag. This is not user-visible in standard C plus TS 18661-1. It
is user detectable with alternate exception handling, as in TS 18661-5 or
with implementation extensions.

Terminology might be confusing here: In 754 we say an operation signals an
exception, where in C we say the operation raises a floating-point
exception. In 754 we say an operation raises an exception flag, where in C
we say the operation sets an exception flag.
>
> 18661 has
>  remainder(+/-0, y) returns +/-0 for y not zero. [Allows y=NaN]
> 754 has
>  r = remainder(x, y) is defined for finite x and y ... (5.3.1)
>  If r = 0, its sign shall be that of x. (5.3.1)
> CONCLUSION:
> 18661-1 needs to encompass these cases:
>  remainder(+/-0, y) returns +/-0 for y finite not zero or infinite.

Hmm. Isn’t that what “y not zero” says? (NaN cases are covered globally.)
>
> 18661 has
>  roundeven() "(that is, to the nearest value whose least significant
>  bit 0)."  It should be "least significant integer bit".
> 754 has
>  no such phrase in (5.3.1, 5.9)
> CONCLUSION:
> 18661-1 needs to say:
> (that is, to the nearest value that is an even integer)
>
> If it's halfway between two integer values, one will be an even integer
> and one value will be an odd integer.  No need to mention bits.

agreed

>
> 18661 has
>  nextup(-HUGE_VAL) is not mentioned.
> 754 has
>  nextup(-inf) is the finite negative number largest in magnitude. (5.3.1)
> CONCLUSION:
> 18661-1 says:
> The nextup functions determine the next representable value,
> in the type of the function, greater than x.
> I think that handles the case nextup(-HUGE_VAL)

Also, in 7.12 (for all C implementations), -HUGE_VAL might not be -inf. See
F.10.8.5 in TS 18661-1 for the 754 C implementation..
>
> 18661 has
>  nextdown(+HUGE_VAL) is not mentioned.
> 754 has
>  nextdown(+inf) is -nextup(-inf) (5.3.1)
> CONCLUSION:
> Same as nextup.
>
> 18661 has
>  canonicalize(SNAN): appears to be missing a domain error in
>  the main body of the standard.
>  Also, for F.10.8.7, canonicalize(SNAN) raises 'invalid'.
> 754 has
>  convertFormat: no mention of SNAN in 5.4.2, but is implied by 6.2
> CONCLUSION:
> In general, the main C standard specifies a domain error where 754
> specifies invalid, right?
> canonicalize is not a 754 function, but if it were, it would probably
> raise invalid on snan.

C doesn’t explicitly specify domain errors for signaling NaN inputs. 7.12.1
says "an implementation may define additional domain errors, provided that
such errors are consistent with the mathematical definition of the
function”, which allows such domain errors.

> 18661
>  Would it be better if fesetexcept() returned the set of flags that
>  were successfully set?
> 754
>  raiseFlags() returns void (5.7.4)
> CONCLUSION:
> I don't think I would use the function value - I'd presumably have
> restricted my set to standard flags.    There's no support for
subexceptions
> in C (and not much in 754).

I’m confused. fetestexcept is a C (not 18661) function. Why is it being
compared to the 754 raiseFlags operation?

>
> 18661
>  fetestexceptflag() returns "OR" of two items; I think it should be
>  "AND".  Also the order of the two arguments is switched from 754.
> 754
>  returns a boolean (5.7.4)
> CONCLUSION:
> Definitely AND.

It says "[3] The fetestexceptflag function returns the value of the bitwise
OR of the floating-point exception macros included in excepts corresponding
to the floating-point exceptions set in *flagp.” There’s effectively an AND
occurring, but the result is an OR of macro values.

> As for argument order, if there's nothing in C to be compatible with,
> then it might as well be compatible with 754.

The argument order is the same as for the C functions getexceptflag and
setexceptflag.

- Jim Thomas

>
> Not sure about min, max, minmag, maxmag, since I am looking at 18661-1
> (2014) and there have been updates to it.
> Not sure about payload related functions as 754 keeps changing.
> CONCLUSION: I'll try to look at these separately.
>


_______________________________________________
Cfp-interest mailing list
Cfp-interest at oakapple.net
https://urldefense.proofpoint.com/v2/url?u=http-3A__mailman.oakapple.net_mailman_listinfo_cfp-2Dinterest&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=md70fwFQha_5ElmLKrMoig&m=-U0ncxdRHo_QRYbeh1aPec3aBndfBEneuHv5vbZiZxM&s=uh9LZYlS-xmz5ejuBCIH-f3IMOnHvvs2SXkGSUYGd64&e=




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20180413/9acf565f/attachment-0003.html 
-------------- 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/20180413/9acf565f/attachment-0003.gif