[Cfp-interest 2716] Re: definition of "floating types"

[Jim Thomas]

> On Feb 28, 2023, at 9:33 AM, Vivian Van Loan <vanloanm at outlook.com> wrote:
> 
> Rajan and I were discussing it in the chat during the meeting and came to a possible solution of "and for other values of FLT_EVAL_METHOD, they are otherwise implementation-defined floating types

This seems to require the _t types to be defined to implementation-defined types. An implementation might define FLT_EVAL_METHOD to -1 because it sometimes evaluates float to double and sometimes to float; the implementation should be able to define float_t to float or double.

> capable of handling only extended real and NaN (if supported) values."

The definition already requires float_t and double_t to be at least as wide as float and double. If “at least as wide as” is understood as implying “includes all the values of” the part about extended real and NaN isn’t needed. Extended real would need accompanying explanation.

If “at least as wide” is ambiguous here, we could say “the values of float are a subset of the values of float_t”, similar to 6.2.5 #12. H.11#6 needs attention in this regard too.

This doesn’t address the issue of whether they should be required to be real floating types, instead of just floating types. If not real floating types, their use would be too limited, e.g. they wouldn’t work in classification or comparison macros.

- Jim Thomas



> , this allows hardware or other types that aren't defined within the standard or implementation fully to be used but excludes things like imaginary or complex types. The specific wording of "if supported" was to cover formats like 360 Hex which doesn't have NaN, and "extended real" was to include inf values (as IEEE-754 defines the extended real numbers as the reals plus infs).
> 
>  -V²L
> From: Cfp-interest <cfp-interest-bounces at oakapple.net> on behalf of Vincent Lefevre <vincent at vinc17.net>
> Sent: Monday, January 30, 2023 12:10 PM
> To: cfp-interest at ucbtest.org <cfp-interest at ucbtest.org>
> Subject: [Cfp-interest 2654] definition of "floating types"
>  
> It seems that the definition of "floating types" is incorrect.
> 
> 6.2.5p15 says: "The real floating and complex types are collectively
> called the /floating types/."
> 
> If I understand correctly, as said like that with italics, there
> cannot be other floating types. But 7.12p3 introduces float_t and
> double_t as floating types. Ditto for H.2.1 and _FloatN, assuming
> that "interchange floating types" are expected to be floating types.
> 
> -- 
> Vincent Lefèvre <vincent at vinc17.net> - Web: <https://www.vinc17.net/>
> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
> _______________________________________________
> Cfp-interest mailing list
> Cfp-interest at oakapple.net
> http://mailman.oakapple.net/mailman/listinfo/cfp-interest
> _______________________________________________
> Cfp-interest mailing list
> Cfp-interest at oakapple.net <mailto:Cfp-interest at oakapple.net>
> http://mailman.oakapple.net/mailman/listinfo/cfp-interest

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20230228/a89dbb76/attachment.htm>