[Cfp-interest] CFP binary FP

[Jim Thomas]

On Dec 9, 2011, at 9:42 AM, Fred J. Tydeman wrote:

> On Fri, 09 Dec 2011 09:15:25 -0800 Jim Thomas wrote:
>>> 7.12.6.7: Not happy with "domain error or range error"
>>> 
>> I used the same words as for ilogb in C1x.
> 
> I understand.  But, I am very unhappy with those words.  It makes a mess.
> 
> Here are the words that I think should be used:
> 
> If x is zero, a domain error occurs and they compute the value of
> FP_LLOGB0;
> 
> if x is infinite, a domain error occurs and they compute the value
> LONG_MAX;
> 
> if x is a NaN, a domain error occurs and they compute the value
> FP_LLOGBNAN;
> 
> ...
> 
> If the correct value is outside the range of the return type, a domain
> error occurs and the numeric result is unspecified.
> 
> OR
> 
> A domain error occurs is x is zero, infinite, or NaN.
> If the correct value is outside the range of the return type, a domain
> error occurs and the numeric result is unspecified.

I'm wanting to be careful about mixing something that should be in a C1x DR into the CFP TS.

> 
>>> Typo:  Page 14: 7.12.14.6: "... the square (as if)…"

right

>>> How get range error for fsqrt?
>>> 
>> fsqrt(DBL_MAX), for example
> 
> I think not.  The exponent of the sqrt is 1/2 of the exponent of
> the argument.  So, overflow or underflow cannot happen.

fsqrt has to deliver a float result. The square root of DBL_MAX won't fit in float.

> 
>>> ISSUE:  If fesetexcept() cannot cause a trap, do we need to add words 
>>> to feraiseexcpet() that it can cause a trap?
>>> Do we need to add words that flags have 3 states:
>>> clear
>>> raised (causing a trap)
>>> set (not causing a trap)
>>> 
>>> 
>> raise and set (using C terminology) put the flags in the same state. 
>> The difference is that raise may cause side effects, namely traps.
> 
> Then, there should be words about these side effects.

There are. See new footnote 4 and the footnote for feraiseexcept in C1x.

> Also, does the order of raising and enabling a trap matter?
> Or, are those words going to happen in part 5 (which I assume
> is the part that will discuss trapping (alternate exceptions))?

I assume you're worrying about deferred traps. I thought we concluded that that was an implementation issue.

-Jim

> 
> ---
> Fred J. Tydeman        Tydeman Consulting
> tydeman at tybor.com      Testing, numerics, programming
> +1 (775) 358-9748      Vice-chair of PL22.11 (ANSI "C")
> Sample C99+FPCE tests: http://www.tybor.com
> Savers sleep well, investors eat well, spenders work forever.
> 
> _______________________________________________
> Cfp-interest mailing list
> Cfp-interest at oakapple.net
> http://mailman.oakapple.net/mailman/listinfo/cfp-interest