[Cfp-interest 1521] request for input

[Jim Thomas]

Request for input ...

In trying to redo the annex for TS-3 to not require support for any particular interchange and extended types, I feel more strongly that this would be the more useful approach. I believe some implementations need nomenclature and rules for at least one extra floating type (for _Float16, _Float80, or _Float128 in particular), but would balk at having to also support _Float32, _Float64, and _Float32x, especially when they already support equivalent types as float and double. 

However, it’s proving exceedingly difficult to describe type interdependencies when which interchange and extended types are supported is entirely up to the implementation. Consider just the prototypes for functions that round to narrower type. TS-3 has:

       _FloatM fMaddfN(_FloatN x, _FloatN y);   // M < N

       _FloatM fMaddfNx(_FloatNx x, _FloatNx y); // M <= N

       _FloatMx fMxaddfN(_FloatN x, _FloatN y); // M < N

       _FloatMx fMxaddfNx(_FloatNx x, _FloatNx y);   // M < N

       _DecimalM dMadddN(_DecimalN x, _DecimalN y);  // M < N

       _DecimalM dMadddNx(_DecimalNx x, _DecimalNx y);    // M <= N

       _DecimalMx dMxadddN(_DecimalN x, _DecimalN y); // M < N

       _DecimalMx dMxadddNx(_DecimalNx x, _DecimalNx y);   // M < N

None of these would exist if the implementation supported only one interchange or extended floating type. Float and double could play the roles of _Float32 and _Float64, but this leads to a very awkward description of the prototypes, and the tgmath rules become even more cumbersome.

One of Jens's ideas was to replace new math functions with type-generic macros. Though this is problematic for math functions in general (see Joseph’s (SC22WG14.17170) N2426), these operations (that round result to specified type) are somewhat special. IEC 60559 describes them as generic operations, e.g., compare the IEC 60559 description of these operations: 

Implementations shall provide the following formatOf general-computational operations, for destinations of all supported arithmetic formats, and, for each destination format, for operands of all supported arithmetic formats with the same radix as the destination format. 

― formatOf-addition(source1, source2)

vs it’s description of other operations such as

Implementations shall provide the following homogeneous general-computational operations for all supported arithmetic formats: 

― sourceFormat roundToIntegralTiesToEven(source)

or

Implementations supporting decimal formats shall provide the following homogeneous general computational operation for all supported decimal arithmetic formats: 

― sourceFormat quantize(source, source)

IEC 60559 leaves language standards flexibility for binding IEC 60559 operations to typed functions or type-generic operations. However, the IEC 60559 description suggests a natural interface. 

Also, these operations (that round to narrower type) are correctly rounded. So, for example, any faddsuffix function invocation would produce the same result provided it’s arguments weren’t narrowed (with loss of range and/or precision) to a parameter type, and It seems unlikely that the user would want a argument for these operations to be narrowed to a parameter type. This suggests that fadd would best be an operator, or a macro that behaves like an operator. As for using a function library from other languages, the fadd macro might be mapped to a typed fadd function with a sufficiently large parameter type, though this might not be optimal for performance.

For function-like macros, e.g., 

	float fadd(x, y), where each argument has a standard or binary floating type or an integer type

the arguments could be treated like by the usual arithmetic conversions (almost), and there would be no need for function prototypes or tgmath macros for them.

What do you think?

- Jim Thomas





-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20200302/c24021ee/attachment.html