[Cfp-interest 1238] Re: part 3 as annex

[Jim Thomas]

> On Jan 22, 2019, at 4:01 PM, Fred J. Tydeman <tydeman at tybor.com> wrote:
> 
> On Sat, 19 Jan 2019 16:10:14 -0800 Jim Thomas wrote:
>> 
>> WG 14 requested we recast TS 18661-3 as a proposed annex for C2X. Here's a draft. Please review it for discussion at this coming week's CFP meeting.
>> 
> 
> Comments on CFP part 3 done as an annex.
> 
> Printed page 3: line 3: Are Interchange floating types compatible with
> other Interchange floating types?  With themselves?  Same for line 32
> and extended floating types.  Perhaps add "(except themselves).

How about 
“Each interchange floating type is not compatible with any other type.”
“Each extended floating type is not compatible with any other type.”

> 
> Surprised that _Decimal32x is not required (and the same as
> _Decimal64).

This might need a sentence of explanation. We’ll discuss it at the teleconference.
> 
> Printed page 7: *_EPSILON: Change "least value greater" to "least
> normalized value greater”.

This should match whatever is said for the other floating types.
> 
> Printed page 13, lines 18-43 versus lines 45 to 20 on next page: differences:
> _FloatN_t

> coshfN
> decodefN
> encodefN
> sinhfN
> tanhfN

Good catch on cosh, sinh, and tanh. 

There are no _t types nor are there decode and encode functions for extended floating types. So those differences are ok.
> 
> Printed page 15, lines 1-29 versus lines 31 to 5 on next page: differences:
> _DecimalN_t
> decodebindN
> decodedecdN
> encodebindN
> encodedecdN

These are ok, as above.
> 
> Printed page 17, line 13: Why 'f' and 'l' suffixes?  And types 'float'
> and 'long double’?

Here and in some other places I’ve shown extended lists instead of just what was added to the lists. This can probably be avoided. Here, we could have: This subclause extends the synopsis by adding other functions, with the same name as the principal function but with fN and fNx suffixes, which are corresponding functions whose parameters and return values have corresponding real types _FloatN and _FloatNx.
> 
> Printed page 19, line 8:  Why 'f' and 'l' suffixes?

How about:
Suffixes fN and fNx are added to the possible suffixes for the functions listed in 7.31.1 (Future library directions for <complex.h>)
> 
> Printed page 20, linee 3 to 5: Why 'f' and 'l' suffixes?  And types
> 'float' and 'long double’?

As above.
> 
> Lines 15-16:  Why are 'float_t' and 'double_t' listed here?

I’d changed this to

With the types
float_t 
double_t
in 7.12 is included the type
long_double_t
> 
> Printed page 37.  I find paragraph 4 confusing.  Is lines 19 and
> following, still part of paragraph 4, or a new paragraph?  If it just
> about the narrower result type, then why lines 32-34 about 3 argument
> functions?

Yes, it’s all one paragraph, about functions that round result to narrower type.

- Jim

> 
> 
> ---
> Fred J. Tydeman        Tydeman Consulting
> tydeman at tybor.com      Testing, numerics, programming
> +1 (702) 608-6093      Vice-chair of PL22.11 (ANSI "C")
> Sample C99+FPCE tests: http://www.tybor.com
> Savers sleep well, investors eat well, spenders work forever.