<html><body><p><font size="2">Does "</font><tt><font size="2">y finite not zero or infinite</font></tt><font size="2">" mean "</font><tt><font size="2">y finite not (zero or infinite)</font></tt><font size="2">" or "</font><tt><font size="2">y finite (not zero) or infinite</font></tt><font size="2">"? Would "</font><tt><font size="2">y finite not zero and not infinite</font></tt><font size="2">" be clearer and have the correct meaning?</font><br><font size="2"><br>- Ian McIntosh IBM Canada Lab Compiler Back End Support and Development<br></font><br><br><img width="16" height="16" src="cid:1__=8FBB08FDDFFCFCF78f9e8a93df938690918c8FB@" border="0" alt="Inactive hide details for Jim Thomas ---2018-04-09 06:07:36 PM---> On Apr 7, 2018, at 2:48 PM, David Hough CFP <pcfp@oakapple.n"><font size="2" color="#424282">Jim Thomas ---2018-04-09 06:07:36 PM---> On Apr 7, 2018, at 2:48 PM, David Hough CFP <pcfp@oakapple.net> wrote: ></font><br><br><font size="2" color="#5F5F5F">From: </font><font size="2">Jim Thomas <jaswthomas@sbcglobal.net></font><br><font size="2" color="#5F5F5F">To: </font><font size="2">David Hough Cfp <cfp-interest@oakapple.net></font><br><font size="2" color="#5F5F5F">Cc: </font><font size="2">CFP <cfp-interest@ucbtest.org></font><br><font size="2" color="#5F5F5F">Date: </font><font size="2">2018-04-09 06:07 PM</font><br><font size="2" color="#5F5F5F">Subject: </font><font size="2">Re: [Cfp-interest] 754 compatibility action item</font><br><font size="2" color="#5F5F5F">Sent by: </font><font size="2">cfp-interest-bounces@oakapple.net</font><br><hr width="100%" size="2" align="left" noshade style="color:#8091A5; "><br><br><br><tt><font size="2"><br><br>> On Apr 7, 2018, at 2:48 PM, David Hough CFP <pcfp@oakapple.net> wrote:<br>> <br>> <br>>> David: Look into the IEEE binding differences to see if they are real=20<br>> issues (from Fred's email on 2018/02/18).<br>> <br>> <br>> min/max and payload are more complex and I will try to look at those<br>> separately.<br>> <br>> Here's my CONCLUSIONS on the simple cases. <br>> Is this what you were looking for?:<br>> <br>> <br>> 18661-1 versus 754<br>> <br>> 18661-1 has<br>> remainder(x, +/-inf) returns x for x not infinite. [Allows x=NaN]<br>> 754 has<br>> remainder(x, inf) is x for finite x. (5.3.1)<br>> remainder(x, inf) is exact for finite normal x. (6.1)<br>> remainder(subnormal, inf) signals underflow. (6.1)<br>> CONCLUSION:<br>> 18661-1 needs to encompass these cases:<br>> remainder(x, +/-inf) returns x for finite x, and if x is subnormal,<br>> raises the "underflow" exception.<br><br>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.<br><br>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.<br>> <br>> 18661 has<br>> remainder(+/-0, y) returns +/-0 for y not zero. [Allows y=NaN]<br>> 754 has<br>> r = remainder(x, y) is defined for finite x and y ... (5.3.1)<br>> If r = 0, its sign shall be that of x. (5.3.1)<br>> CONCLUSION:<br>> 18661-1 needs to encompass these cases:<br>> remainder(+/-0, y) returns +/-0 for y finite not zero or infinite.<br><br>Hmm. Isn’t that what “y not zero” says? (NaN cases are covered globally.)<br>> <br>> 18661 has<br>> roundeven() "(that is, to the nearest value whose least significant<br>> bit 0)." It should be "least significant integer bit".<br>> 754 has<br>> no such phrase in (5.3.1, 5.9)<br>> CONCLUSION:<br>> 18661-1 needs to say:<br>> (that is, to the nearest value that is an even integer)<br>> <br>> If it's halfway between two integer values, one will be an even integer<br>> and one value will be an odd integer. No need to mention bits.<br><br>agreed<br><br>> <br>> 18661 has<br>> nextup(-HUGE_VAL) is not mentioned.<br>> 754 has<br>> nextup(-inf) is the finite negative number largest in magnitude. (5.3.1)<br>> CONCLUSION:<br>> 18661-1 says: <br>> The nextup functions determine the next representable value, <br>> in the type of the function, greater than x.<br>> I think that handles the case nextup(-HUGE_VAL)<br><br>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..<br>> <br>> 18661 has<br>> nextdown(+HUGE_VAL) is not mentioned.<br>> 754 has<br>> nextdown(+inf) is -nextup(-inf) (5.3.1)<br>> CONCLUSION:<br>> Same as nextup.<br>> <br>> 18661 has<br>> canonicalize(SNAN): appears to be missing a domain error in<br>> the main body of the standard.<br>> Also, for F.10.8.7, canonicalize(SNAN) raises 'invalid'.<br>> 754 has<br>> convertFormat: no mention of SNAN in 5.4.2, but is implied by 6.2<br>> CONCLUSION:<br>> In general, the main C standard specifies a domain error where 754<br>> specifies invalid, right?<br>> canonicalize is not a 754 function, but if it were, it would probably<br>> raise invalid on snan.<br><br>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.<br><br>> 18661<br>> Would it be better if fesetexcept() returned the set of flags that<br>> were successfully set?<br>> 754<br>> raiseFlags() returns void (5.7.4)<br>> CONCLUSION:<br>> I don't think I would use the function value - I'd presumably have <br>> restricted my set to standard flags. There's no support for subexceptions<br>> in C (and not much in 754).<br><br>I’m confused. fetestexcept is a C (not 18661) function. Why is it being compared to the 754 raiseFlags operation?<br><br>> <br>> 18661<br>> fetestexceptflag() returns "OR" of two items; I think it should be<br>> "AND". Also the order of the two arguments is switched from 754.<br>> 754<br>> returns a boolean (5.7.4)<br>> CONCLUSION:<br>> Definitely AND.<br><br>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.<br><br>> As for argument order, if there's nothing in C to be compatible with,<br>> then it might as well be compatible with 754.<br><br>The argument order is the same as for the C functions getexceptflag and setexceptflag.<br><br>- Jim Thomas<br><br>> <br>> Not sure about min, max, minmag, maxmag, since I am looking at 18661-1<br>> (2014) and there have been updates to it.<br>> Not sure about payload related functions as 754 keeps changing.<br>> CONCLUSION: I'll try to look at these separately.<br>> <br><br><br>_______________________________________________<br>Cfp-interest mailing list<br>Cfp-interest@oakapple.net<br></font></tt><tt><font size="2"><a href="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=">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=</a></font></tt><tt><font size="2"><br><br></font></tt><br><br><BR>
</body></html>