[Cfp-interest] TS draft comments

[Jim Thomas]

Thanks, Fred. See below ...

On Jan 14, 2012, at 10:45 PM, Fred J. Tydeman wrote:

> On Sat, 14 Jan 2012 09:25:29 -0800 Jim Thomas wrote:
>> 
>> This is a reminder that I have to submit our TS Part 1 draft on Monday Jan 16 for the C committee mailing. So please send me your comments ASAP. 
>> 
> 
> 1. Conformance
> Why "hosted"?  Why not also embedded?

C11 doesn't mention embedded systems. What are you referring to?

> 
> 6.2 Canonical encodings
> "redundant of ill-specified" ??? Perhaps 'of' should be 'or'

Yes, should be "or".

> 
> 7 Operation binding
> logb entry would be better as: logb, ilogb, llogb

Ok.

> 
> "resotreModes" -> "restoreModes"

Yes.

> 
> 9 Conversions between ...
> 
> When converting between decimal character sequences and binary FP with
> more than CR_DECIMAL_DIG digits, what rounding mode is used to round
> to CR_DECIMAL_DIG?  Is it the binary or the decimal rounding mode?

The binary rounding direction mode determines the direction of rounding. The binary rounding direction mode is the only rounding direction mode defined for Part 1 of the TS.


> 
> 10 Constant rounding directions
> Page 11, 2nd paragraph:  "pragma is effect" -> "pragma is in effect"

Yes.

> 
> Page 11, 3rd paragraph:  "was addressed with change use" ????

Should have been "was addressed with the change to use". The ISSUE has been removed.

> 
> Page 11, 4th paragraph:  "RAMF" -- spell out

Yes (unless we can get it done and remove the ISSUE).

> 
> 11 NaN support
> "each is defined if and if"  -- needs an "only"

Yes.

> 
> 12.1 Nearest integer functions
> Seems like the WIDTH macros (current section 14) should be before
> 7.12.9.9 The fromfp and ufromfp functions.

Maybe that would be better. I'd l like to avoid a lot of section renumberings, so would prefer to wait until later. Forward references is another thing to add later.

> 
> Do F.19.9.4 and F.19.9.5 need 'quiet' before NaN?

There's no F.19.

> 
> Do F.10.8.3 and F.10.8.4 need to specify -0 cases?

Yikes. This looks like a flaw in the definition of nextafter in clause 7. It refers to "the next representable value", which might lead one to think nextafter(-0.0, 1.0) would be +0.0. IEEE 754-1985 said "next representable neighbor". This could be a DR, after we come up with good words.

> 
> What do the fe*except* functions do if the excepts argument is not a
> valid exception (such as the value -1)?

7.6.2 says the behavior of these functions is implementation-defined.

-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.