------=_Part_2287_135608177.1487876154640
Content-Type: multipart/alternative;
 boundary="----=_Part_2288_1168495025.1487876154640"

------=_Part_2288_1168495025.1487876154640
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

C99, C++11 and later introduced standardized fixed-width integer types such=
=20
as int32_t provided in the headers stdint.h/cstdint and inttypes.h/cinttype=
s.=20
However, although the float  and double data types conventionally are=20
implemented with, respectively, IEC 559 binary32 and binary64 format and=20
semantics, and long double as a typedef of double, this is not specified by=
=20
the standard.

There is therefore a need for floating-point types with well-defined format=
=20
and semantics, which could be provided in existing headers such as cfloat o=
r=20
cmath, or a new header perhaps called float, stdfloat or floattypes.

32-bit and 64-bit base-2 floating-point numbers with fixed semantics, such=
=20
that arithmetic expressions resulting in these types may not be transformed=
=20
in any way that alters the result of the expression, even if no precision=
=20
is lost. The set of values of type f64_t must be a superset of the set of=
=20
values of type f32_t.

f32_t
f64_t

IEC 559 binary32/64 format and semantics.

f32_iec559_t
f64_iec559_t

32-bit and 64-bit base-2 floating-point numbers whose sets of values are=20
supersets of the non-subnormal subsets of IEC 559 binary32/64,=20
respectively. Arithmetic expressions resulting in these types may result in=
=20
any non-subnormal value at least as precise as provided IEC 559 binary=20
floating point arithmetic. Support for subnormal values of these types is=
=20
implementation-defined.

f32_fast_t
f64_fast_t

Equivalent to f32_iec559_t and f64_iec559_t, but trap on arithmetic errors=
=20
(inexact, underflow, overflow, divide-by-zero, invalid), or when they hold=
=20
the values +/-NAN or +/-INFINITY.

f32_trap_t
f64_trap_t

Equivalent to f32_trap_t and f64_trap_t, but throw a C++ exception instead=
=20
of trapping.

f32_throw_t
f64_throw_t

In addition, implementations may optionally provide any or all of the=20
following types for fixed-width binary floating-point numbers with=20
standardized semantics, =E2=80=A6

f8_t
f16_t
f80_t
f128_t
f256_t
f16_iec559_t
f128_iec559_t
f256_iec559_t
f8_fast_t
f16_fast_t
f80_fast_t
f128_fast_t
f256_fast_t
f8_trap_t
f16_trap_t
f80_trap_t
f128_trap_t
f256_trap_t
f8_throw_t
f16_throw_t
f80_throw_t
f128_throw_t
f256_throw_t

=E2=80=A6 and may also optionally provide any or all of the following types=
 for=20
fixed-width decimal floating-point numbers with standardized semantics.

dec32_t
dec64_t
dec128_t
dec32_iec559_t
dec64_iec559_t
dec128_iec559_t
dec32_fast_t
dec64_fast_t
dec128_fast_t
dec32_trap_t
dec64_trap_t
dec128_trap_t
dec32_throw_t
dec64_throw_t
dec128_throw_t

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/bb6f426e-0dfd-4847-b933-170560053491%40isocpp.or=
g.

------=_Part_2288_1168495025.1487876154640
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">C99, C++11 and later introduced standardized fixed-width i=
nteger types such as <font face=3D"courier new, monospace">int32_t</font> p=
rovided in the headers <font face=3D"courier new, monospace">stdint.h</font=
>/<font face=3D"courier new, monospace">cstdint</font> and <font face=3D"co=
urier new, monospace">inttypes.h</font>/<font face=3D"courier new, monospac=
e">cinttypes</font>. However, although the <font face=3D"courier new, monos=
pace">float</font>=C2=A0 and <font face=3D"courier new, monospace">double</=
font> data types conventionally are implemented with, respectively, IEC 559=
 binary32 and binary64 format and semantics, and <font face=3D"courier new,=
 monospace">long double</font> as a typedef of <font face=3D"courier new, m=
onospace">double</font>, this is not specified by the standard.<div><br></d=
iv><div>There is therefore a need for floating-point types with well-define=
d format and semantics, which could be provided in existing headers such as=
=C2=A0<font face=3D"courier new, monospace">cfloat</font><font face=3D"aria=
l, sans-serif">=C2=A0or </font><font face=3D"courier new, monospace">cmath<=
/font>,<font face=3D"arial, sans-serif">=C2=A0or a new header perhaps calle=
d </font><font face=3D"courier new, monospace">float</font><font face=3D"ar=
ial, sans-serif">, </font><font face=3D"courier new, monospace">stdfloat</f=
ont><font face=3D"arial, sans-serif"> or </font><font face=3D"courier new, =
monospace">floattypes</font><font face=3D"arial, sans-serif">.</font></div>=
<div><font face=3D"arial, sans-serif"><br></font></div><div><div><font face=
=3D"arial, sans-serif">32-bit and 64-bit base-2 floating-point numbers with=
 fixed semantics, such that arithmetic expressions resulting in these types=
 may not be transformed in any way that alters the result of the expression=
, even if no precision is lost. The set of values of type </font><font face=
=3D"courier new, monospace">f64_t</font><font face=3D"arial, sans-serif"> m=
ust be a superset of the set of values of type </font><font face=3D"courier=
 new, monospace">f32_t</font><font face=3D"arial, sans-serif">.</font></div=
><div><font face=3D"arial, sans-serif"><br></font></div><div class=3D"prett=
yprint" style=3D"background-color: rgb(250, 250, 250); border-color: rgb(18=
7, 187, 187); border-style: solid; border-width: 1px; word-wrap: break-word=
;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D=
"color: #000;" class=3D"styled-by-prettify">f32_t<br>f64_t</span></div></co=
de></div><div><br></div><div><font face=3D"arial, sans-serif">IEC 559 binar=
y32/64 format and semantics.</font></div><div><font face=3D"arial, sans-ser=
if"><br></font></div><div class=3D"prettyprint" style=3D"background-color: =
rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; =
border-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div=
 class=3D"subprettyprint"><span style=3D"color: #000;" class=3D"styled-by-p=
rettify">f32_iec559_t<br>f64_iec559_t</span></div></code></div><div><br></d=
iv><div><font face=3D"arial, sans-serif">32-bit and 64-bit base-2 floating-=
point numbers whose sets of values are supersets of the non-subnormal subse=
ts of IEC 559 binary32/64, respectively. Arithmetic expressions resulting i=
n these types may result in any non-subnormal value at least as precise as =
provided IEC 559 binary floating point arithmetic. Support for subnormal va=
lues of these types is implementation-defined.</font></div><div><font face=
=3D"arial, sans-serif"><br></font></div><div class=3D"prettyprint" style=3D=
"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); bo=
rder-style: solid; border-width: 1px; word-wrap: break-word;"><code class=
=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #000;"=
 class=3D"styled-by-prettify">f32_fast_t<br>f64_fast_t</span></div></code><=
/div><div><br></div><div><font face=3D"arial, sans-serif">Equivalent to </f=
ont><font face=3D"courier new, monospace">f32_iec559_t</font><font face=3D"=
arial, sans-serif"> and </font><font face=3D"courier new, monospace">f64_ie=
c559_t</font><font face=3D"arial, sans-serif">, but trap on arithmetic erro=
rs (inexact, underflow, overflow, divide-by-zero, invalid), or when they ho=
ld the values </font><font face=3D"courier new, monospace">+</font><font fa=
ce=3D"arial, sans-serif">/</font><font face=3D"courier new, monospace">-NAN=
</font><font face=3D"arial, sans-serif"> or </font><font face=3D"courier ne=
w, monospace">+</font><font face=3D"arial, sans-serif">/</font><font face=
=3D"courier new, monospace">-INFINITY</font><font face=3D"arial, sans-serif=
">.</font></div><div><font face=3D"arial, sans-serif"><br></font></div><div=
 class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); borde=
r-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-w=
rap: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"=
><span style=3D"color: #000;" class=3D"styled-by-prettify">f32_trap_t<br>f6=
4_trap_t</span></div></code></div><div><font face=3D"arial, sans-serif"><br=
></font></div><div><font face=3D"arial, sans-serif">Equivalent to </font><f=
ont face=3D"courier new, monospace">f32_trap_t</font><font face=3D"arial, s=
ans-serif"> and </font><font face=3D"courier new, monospace">f64_trap_t</fo=
nt><font face=3D"arial, sans-serif">, but throw a C++ exception instead of =
trapping.</font></div><div><font face=3D"arial, sans-serif"><br></font></di=
v><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250);=
 border-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; =
word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subpretty=
print"><span style=3D"color: #000;" class=3D"styled-by-prettify">f32_throw_=
t<br>f64_throw_t</span></div></code></div><div><br></div><div><font face=3D=
"arial, sans-serif">In addition, implementations may optionally provide any=
 or all of the following types for fixed-width binary floating-point number=
s with standardized semantics, =E2=80=A6</font></div><div><font face=3D"ari=
al, sans-serif"><br></font></div><div class=3D"prettyprint" style=3D"backgr=
ound-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-st=
yle: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"prett=
yprint"><div class=3D"subprettyprint"><span style=3D"color: #000;" class=3D=
"styled-by-prettify">f8_t<br>f16_t<br>f80_t<br>f128_t<br>f256_t<br>f16_iec5=
59_t<br>f128_iec559_t<br>f256_iec559_t<br>f8_fast_t<br>f16_fast_t<br>f80_fa=
st_t<br>f128_fast_t<br>f256_fast_t<br>f8_trap_t<br>f16_trap_t<br>f80_trap_t=
<br>f128_trap_t<br>f256_trap_t<br>f8_throw_t<br>f16_throw_t<br>f80_throw_t<=
br>f128_throw_t<br>f256_throw_t</span></div></code></div><div><br></div><di=
v><font face=3D"arial, sans-serif">=E2=80=A6 and may also optionally provid=
e any or all of the following types for fixed-width decimal floating-point =
numbers with standardized semantics.</font></div><div><font face=3D"arial, =
sans-serif"><br></font></div><div class=3D"prettyprint" style=3D"background=
-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style:=
 solid; border-width: 1px; word-wrap: break-word;"><code class=3D"prettypri=
nt"><div class=3D"subprettyprint"><span style=3D"color: #000;" class=3D"sty=
led-by-prettify">dec32_t<br>dec64_t<br>dec128_t<br>dec32_iec559_t<br>dec64_=
iec559_t<br>dec128_iec559_t<br>dec32_fast_t<br>dec64_fast_t<br>dec128_fast_=
t<br>dec32_trap_t<br>dec64_trap_t<br>dec128_trap_t<br>dec32_throw_t<br>dec6=
4_throw_t<br>dec128_throw_t</span></div></code></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/bb6f426e-0dfd-4847-b933-170560053491%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/bb6f426e-0dfd-4847-b933-170560053491=
%40isocpp.org</a>.<br />

------=_Part_2288_1168495025.1487876154640--

------=_Part_2287_135608177.1487876154640--

.

On 2017-02-23 13:55, Ray Hamel wrote:
> C99, C++11 and later introduced standardized fixed-width integer types such
> as int32_t provided in the headers stdint.h/cstdint and inttypes.h/cinttypes.
> However, although the float  and double data types conventionally are
> implemented with, respectively, IEC 559 binary32 and binary64 format and
> semantics, and long double as a typedef of double, this is not specified by
> the standard.
>
> There is therefore a need for floating-point types with well-defined format
> and semantics, which could be provided in existing headers such as cfloat or
> cmath, or a new header perhaps called float, stdfloat or floattypes.

This seems reasonable to me at least. Please however name them e.g.
float32_t, for consistency:

  int, short, long -> intN_t
  float, double -> floatN_t

Given the int types are in cstdint, I guess the float types should be in
cstdfloat. This suggests however that you should talk to WG14 first...

Certainly the _fast variations make sense. I'm not sure how practical
the others are. Possibly _ieee754 makes sense to the extent that these
can either exist if floating point uses IEEE 754, or not exist
otherwise. Do non-IEEE compilers have a way of declaring an IEEE float
even if plain `float` is something else? For similar reasons, I'm not
sure if _trap, etc. variants are possible.

If you're going to have _fast, you should probably consider having
_least, also, especially if you have float80 variants, since a platform
might have float_least80_t -> float128_t but not have float80_t.

--
Matthew

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/58AF3D1E.4010002%40gmail.com.

.

------=_Part_2426_1704030405.1487884035294
Content-Type: multipart/alternative;
 boundary="----=_Part_2427_1753545026.1487884035295"

------=_Part_2427_1753545026.1487884035295
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thursday, February 23, 2017 at 2:50:59 PM UTC-5, Matthew Woehlke wrote:
>
> This seems reasonable to me at least. Please however name them e.g.=20
> float32_t, for consistency:=20
>
>   int, short, long -> intN_t=20
>   float, double -> floatN_t=20
>
=20
I was unsure of which way to go on that; I thought if I used the whole word=
=20
"float" the longer types would start to get a bit ungainly. I also think=20
that floatN_t might be somewhat harder to visually distinguish from plain=
=20
float than intN_t is from int. What do you think?

static inline constexpr const volatile int _t_n;
static inline constexpr const volatile int8_t n;
static inline constexpr const volatile float _t_f;
static inline constexpr const volatile float8_t f;

Agreed that floatN_t would be more consistent =E2=80=94 s/f(\d)/float\1/g o=
n the OP=20
unless others think differently.

Given the int types are in cstdint, I guess the float types should be in=20
> cstdfloat. This suggests however that you should talk to WG14 first...=20
>
=20
Do they have a public mailing list? I wasn't able to find one. In any case,=
=20
since this is far from a formal proposal, any feedback I could get here or=
=20
there is useful.

Certainly the _fast variations make sense. I'm not sure how practical=20
> the others are. Possibly _ieee754 makes sense to the extent that these=20
> can either exist if floating point uses IEEE 754, or not exist=20
> otherwise. Do non-IEEE compilers have a way of declaring an IEEE float=20
> even if plain `float` is something else?


I'm not sure. I know IEEE 754 is possible to implement in software and=20
there are compilers that do so for platforms that don't support it in=20
hardware. I refer to it as IEC 559 here because that's how it's referred to=
=20
in the standard.
=20

> For similar reasons, I'm not sure if _trap, etc. variants are possible.
>

IEEE 754 specifies that those five floating-point exceptions be recorded in=
=20
the floating-point status word, so those variants should be trivial to=20
implement (possible at the library level with C++, would require compiler=
=20
support with C). But if not they could also be made optional.
=20

> If you're going to have _fast, you should probably consider having=20
> _least, also, especially if you have float80 variants, since a platform=
=20
> might have float_least80_t -> float128_t but not have float80_t.=20
>

Good idea.

- Ray=20

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/73100d4d-d725-4afc-8f29-270154335d77%40isocpp.or=
g.

------=_Part_2427_1753545026.1487884035295
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thursday, February 23, 2017 at 2:50:59 PM UTC-5, Matthe=
w Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">This seems rea=
sonable to me at least. Please however name them e.g.
<br>float32_t, for consistency:
<br>
<br>=C2=A0 int, short, long -&gt; intN_t
<br>=C2=A0 float, double -&gt; floatN_t
<br></blockquote><div>=C2=A0</div><div>I was unsure of which way to go on t=
hat; I thought if I used the whole word &quot;float&quot; the longer types =
would start to get a bit ungainly. I also think that <font face=3D"courier =
new, monospace">floatN_t</font> might be somewhat harder to visually distin=
guish from plain <font face=3D"courier new, monospace">float</font> than <f=
ont face=3D"courier new, monospace">intN_t</font> is from <font face=3D"cou=
rier new, monospace">int</font>. What do you think?</div><div><br></div><di=
v class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); bord=
er-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-=
wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint=
"><span style=3D"color: #008;" class=3D"styled-by-prettify">static</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">inline</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #0=
08;" class=3D"styled-by-prettify">constexpr</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">const</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">volatile</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">i=
nt</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> _t_n</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">static</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #0=
08;" class=3D"styled-by-prettify">inline</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D=
"styled-by-prettify">constexpr</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by=
-prettify">const</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">vol=
atile</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> int8=
_t n</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><spa=
n style=3D"color: #008;" class=3D"styled-by-prettify">static</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">inline</span><span style=3D"color:=
 #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" c=
lass=3D"styled-by-prettify">constexpr</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">const</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">volatile</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">float</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> _t_f</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"=
color: #008;" class=3D"styled-by-prettify">static</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;"=
 class=3D"styled-by-prettify">inline</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">constexpr</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pre=
ttify">const</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">volatil=
e</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> float8_t=
 f</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div>=
</code></div><div><br></div><div>Agreed that <font face=3D"courier new, mon=
ospace">floatN_t</font><font face=3D"arial, sans-serif">=C2=A0would be more=
 consistent =E2=80=94 </font><font face=3D"courier new, monospace">s/f(\d)/=
float\1/g</font><font face=3D"arial, sans-serif"> on the OP unless others t=
hink differently.</font></div><div><br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddi=
ng-left: 1ex;">Given the int types are in cstdint, I guess the float types =
should be in
<br>cstdfloat. This suggests however that you should talk to WG14 first...
<br></blockquote><div>=C2=A0</div><div>Do they have a public mailing list? =
I wasn&#39;t able to find one. In any case, since this is far from a formal=
 proposal, any feedback I could get here or there is useful.</div><div><br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;">Certainly the _fast vari=
ations make sense. I&#39;m not sure how practical
<br>the others are. Possibly _ieee754 makes sense to the extent that these
<br>can either exist if floating point uses IEEE 754, or not exist
<br>otherwise. Do non-IEEE compilers have a way of declaring an IEEE float
<br>even if plain `float` is something else?</blockquote><div><br></div><di=
v>I&#39;m not sure. I know IEEE 754 is possible to implement in software an=
d there are compilers that do so for platforms that don&#39;t support it in=
 hardware. I refer to it as IEC 559 here because that&#39;s how it&#39;s re=
ferred to in the standard.</div><div>=C2=A0</div><blockquote class=3D"gmail=
_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;p=
adding-left: 1ex;">For similar reasons, I&#39;m not
sure if _trap, etc. variants are possible.<br></blockquote><div><br></div><=
div>IEEE 754 specifies that those five floating-point exceptions be recorde=
d in the floating-point status word, so those variants should be trivial to=
 implement (possible at the library level with C++, would require compiler =
support with C). But if not they could also be made optional.</div><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">If you&#39;re going t=
o have _fast, you should probably consider having
<br>_least, also, especially if you have float80 variants, since a platform
<br>might have float_least80_t -&gt; float128_t but not have float80_t.
<br></blockquote><div><br></div><div>Good idea.</div><div><br></div><div>- =
Ray=C2=A0</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/73100d4d-d725-4afc-8f29-270154335d77%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/73100d4d-d725-4afc-8f29-270154335d77=
%40isocpp.org</a>.<br />

------=_Part_2427_1753545026.1487884035295--

------=_Part_2426_1704030405.1487884035294--

.

------=_Part_2417_1904561749.1487892909105
Content-Type: multipart/alternative;
 boundary="----=_Part_2418_1566122481.1487892909105"

------=_Part_2418_1566122481.1487892909105
Content-Type: text/plain; charset=UTF-8

One of the problems you're going to run into here is that the specialized
integer types were inherited from C99. They were based on existing practice
among a number of compilers. GCC, MSVC, and others had built-in sized
integer types. And these new integers fit into a standardization paradigm
that included "extended integers": implementation-defined integer types
that were not the standard integer types. The standard explicitly allowed
implementations to add them.

What you're doing here is creating something from whole cloth, with no
existing practice among a number of compilers. Nobody has `float32_t`
typedefs out there or something similar. There is no standard framework for
implementation-defined floating point types.

Also, the only standard-defined integer type whose implementation is fixed
to a specific set of rules is the `(u)intXX_t` series of integers; they are
required to be two's complement. And they're also *optional*. If a platform
doesn't support two's complement, they just don't implement them.

What you seem to want is for compilers to implement a bunch of floating
point types with *required* behavior. To *force* compilers to implement a
bunch of different potential floating-point types.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/db8f8f94-4386-4eb7-a4d9-550a836aeaa3%40isocpp.org.

------=_Part_2418_1566122481.1487892909105
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">One of the problems you&#39;re going to run into here is t=
hat the specialized integer types were inherited from C99. They were based =
on existing practice among a number of compilers. GCC, MSVC, and others had=
 built-in sized integer types. And these new integers fit into a standardiz=
ation paradigm that included &quot;extended integers&quot;: implementation-=
defined integer types that were not the standard integer types. The standar=
d explicitly allowed implementations to add them.<br><br>What you&#39;re do=
ing here is creating something from whole cloth, with no existing practice =
among a number of compilers. Nobody has `float32_t` typedefs out there or s=
omething similar. There is no standard framework for implementation-defined=
 floating point types.<br><br>Also, the only standard-defined integer type =
whose implementation is fixed to a specific set of rules is the `(u)intXX_t=
` series of integers; they are required to be two&#39;s complement. And the=
y&#39;re also <i>optional</i>. If a platform doesn&#39;t support two&#39;s =
complement, they just don&#39;t implement them.<br><br>What you seem to wan=
t is for compilers to implement a bunch of floating point types with <i>req=
uired</i> behavior. To <i>force</i> compilers to implement a bunch of diffe=
rent potential floating-point types.<br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/db8f8f94-4386-4eb7-a4d9-550a836aeaa3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/db8f8f94-4386-4eb7-a4d9-550a836aeaa3=
%40isocpp.org</a>.<br />

------=_Part_2418_1566122481.1487892909105--

------=_Part_2417_1904561749.1487892909105--

.

On 23.02.2017 20:50, Matthew Woehlke wrote:
>
> Certainly the _fast variations make sense.

Note that they are already available under a different name:
std::float_t is an alias to a floating point at least as big as float,
std::double_t is an alias to a floating point at least as big as double.
It is designed to be the more efficient type.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f512cd64-b900-980c-9f18-b35b19cc7ec2%40gmail.com.

.

------=_Part_514_479166942.1488044689135
Content-Type: multipart/alternative;
 boundary="----=_Part_515_1355129295.1488044689136"

------=_Part_515_1355129295.1488044689136
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thursday, February 23, 2017 at 7:55:54 PM UTC+1, Ray Hamel wrote:
>
> C99, C++11 and later introduced standardized fixed-width integer types=20
> such as int32_t provided in the headers stdint.h/cstdint and inttypes.h/
> cinttypes. However, although the float  and double data types=20
> conventionally are implemented with, respectively, IEC 559 binary32 and=
=20
> binary64 format and semantics, and long double as a typedef of double,=20
> this is not specified by the standard.
>
> There is therefore a need for floating-point types with well-defined=20
> format and semantics, which could be provided in existing headers such as=
=20
> cfloat or cmath, or a new header perhaps called float, stdfloat or=20
> floattypes.
>
> 32-bit and 64-bit base-2 floating-point numbers with fixed semantics, suc=
h=20
> that arithmetic expressions resulting in these types may not be transform=
ed=20
> in any way that alters the result of the expression, even if no precision=
=20
> is lost. The set of values of type f64_t must be a superset of the set of=
=20
> values of type f32_t.
>
> f32_t
> f64_t
>
> IEC 559 binary32/64 format and semantics.
>
> f32_iec559_t
> f64_iec559_t
>
> 32-bit and 64-bit base-2 floating-point numbers whose sets of values are=
=20
> supersets of the non-subnormal subsets of IEC 559 binary32/64,=20
> respectively. Arithmetic expressions resulting in these types may result =
in=20
> any non-subnormal value at least as precise as provided IEC 559 binary=20
> floating point arithmetic. Support for subnormal values of these types is=
=20
> implementation-defined.
>
> f32_fast_t
> f64_fast_t
>
> Equivalent to f32_iec559_t and f64_iec559_t, but trap on arithmetic=20
> errors (inexact, underflow, overflow, divide-by-zero, invalid), or when=
=20
> they hold the values +/-NAN or +/-INFINITY.
>
> f32_trap_t
> f64_trap_t
>
> Equivalent to f32_trap_t and f64_trap_t, but throw a C++ exception=20
> instead of trapping.
>
> f32_throw_t
> f64_throw_t
>
> In addition, implementations may optionally provide any or all of the=20
> following types for fixed-width binary floating-point numbers with=20
> standardized semantics, =E2=80=A6
>
> f8_t
> f16_t
> f80_t
> f128_t
> f256_t
> f16_iec559_t
> f128_iec559_t
> f256_iec559_t
> f8_fast_t
> f16_fast_t
> f80_fast_t
> f128_fast_t
> f256_fast_t
> f8_trap_t
> f16_trap_t
> f80_trap_t
> f128_trap_t
> f256_trap_t
> f8_throw_t
> f16_throw_t
> f80_throw_t
> f128_throw_t
> f256_throw_t
>
> =E2=80=A6 and may also optionally provide any or all of the following typ=
es for=20
> fixed-width decimal floating-point numbers with standardized semantics.
>
> dec32_t
> dec64_t
> dec128_t
> dec32_iec559_t
> dec64_iec559_t
> dec128_iec559_t
> dec32_fast_t
> dec64_fast_t
> dec128_fast_t
> dec32_trap_t
> dec64_trap_t
> dec128_trap_t
> dec32_throw_t
> dec64_throw_t
> dec128_throw_t
>
=20
GCC7 (in C mode) has support for _Float32, etc based on ISO/IEC TS=20
18661-3:2015. You may want to discuss the relation with that TS in your=20
proposal.

https://gcc.gnu.org/ml/gcc-patches/2016-08/msg01290.html

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/47e6dde8-9ff5-4950-b385-029b9f81fe62%40isocpp.or=
g.

------=_Part_515_1355129295.1488044689136
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thursday, February 23, 2017 at 7:55:54 PM UTC+1, Ray Ha=
mel wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">C99=
, C++11 and later introduced standardized fixed-width integer types such as=
 <font face=3D"courier new, monospace">int32_t</font> provided in the heade=
rs <font face=3D"courier new, monospace">stdint.h</font>/<font face=3D"cour=
ier new, monospace">cstdint</font> and <font face=3D"courier new, monospace=
">inttypes.h</font>/<font face=3D"courier new, monospace">cinttypes</font>.=
 However, although the <font face=3D"courier new, monospace">float</font>=
=C2=A0 and <font face=3D"courier new, monospace">double</font> data types c=
onventionally are implemented with, respectively, IEC 559 binary32 and bina=
ry64 format and semantics, and <font face=3D"courier new, monospace">long d=
ouble</font> as a typedef of <font face=3D"courier new, monospace">double</=
font>, this is not specified by the standard.<div><br></div><div>There is t=
herefore a need for floating-point types with well-defined format and seman=
tics, which could be provided in existing headers such as=C2=A0<font face=
=3D"courier new, monospace">cfloat</font><font face=3D"arial, sans-serif">=
=C2=A0or </font><font face=3D"courier new, monospace">cmath</font>,<font fa=
ce=3D"arial, sans-serif">=C2=A0or a new header perhaps called </font><font =
face=3D"courier new, monospace">float</font><font face=3D"arial, sans-serif=
">, </font><font face=3D"courier new, monospace">stdfloat</font><font face=
=3D"arial, sans-serif"> or </font><font face=3D"courier new, monospace">flo=
attypes</font><font face=3D"arial, sans-serif">.</font></div><div><font fac=
e=3D"arial, sans-serif"><br></font></div><div><div><font face=3D"arial, san=
s-serif">32-bit and 64-bit base-2 floating-point numbers with fixed semanti=
cs, such that arithmetic expressions resulting in these types may not be tr=
ansformed in any way that alters the result of the expression, even if no p=
recision is lost. The set of values of type </font><font face=3D"courier ne=
w, monospace">f64_t</font><font face=3D"arial, sans-serif"> must be a super=
set of the set of values of type </font><font face=3D"courier new, monospac=
e">f32_t</font><font face=3D"arial, sans-serif">.</font></div><div><font fa=
ce=3D"arial, sans-serif"><br></font></div><div style=3D"background-color:rg=
b(250,250,250);border-color:rgb(187,187,187);border-style:solid;border-widt=
h:1px;word-wrap:break-word"><code><div><span style=3D"color:#000">f32_t<br>=
f64_t</span></div></code></div><div><br></div><div><font face=3D"arial, san=
s-serif">IEC 559 binary32/64 format and semantics.</font></div><div><font f=
ace=3D"arial, sans-serif"><br></font></div><div style=3D"background-color:r=
gb(250,250,250);border-color:rgb(187,187,187);border-style:solid;border-wid=
th:1px;word-wrap:break-word"><code><div><span style=3D"color:#000">f32_iec5=
59_t<br>f64_iec559_t</span></div></code></div><div><br></div><div><font fac=
e=3D"arial, sans-serif">32-bit and 64-bit base-2 floating-point numbers who=
se sets of values are supersets of the non-subnormal subsets of IEC 559 bin=
ary32/64, respectively. Arithmetic expressions resulting in these types may=
 result in any non-subnormal value at least as precise as provided IEC 559 =
binary floating point arithmetic. Support for subnormal values of these typ=
es is implementation-defined.</font></div><div><font face=3D"arial, sans-se=
rif"><br></font></div><div style=3D"background-color:rgb(250,250,250);borde=
r-color:rgb(187,187,187);border-style:solid;border-width:1px;word-wrap:brea=
k-word"><code><div><span style=3D"color:#000">f32_fast_t<br>f64_fast_t</spa=
n></div></code></div><div><br></div><div><font face=3D"arial, sans-serif">E=
quivalent to </font><font face=3D"courier new, monospace">f32_iec559_t</fon=
t><font face=3D"arial, sans-serif"> and </font><font face=3D"courier new, m=
onospace">f64_iec559_t</font><font face=3D"arial, sans-serif">, but trap on=
 arithmetic errors (inexact, underflow, overflow, divide-by-zero, invalid),=
 or when they hold the values </font><font face=3D"courier new, monospace">=
+</font><font face=3D"arial, sans-serif">/</font><font face=3D"courier new,=
 monospace">-NAN</font><font face=3D"arial, sans-serif"> or </font><font fa=
ce=3D"courier new, monospace">+</font><font face=3D"arial, sans-serif">/</f=
ont><font face=3D"courier new, monospace">-INFINITY</font><font face=3D"ari=
al, sans-serif">.</font></div><div><font face=3D"arial, sans-serif"><br></f=
ont></div><div style=3D"background-color:rgb(250,250,250);border-color:rgb(=
187,187,187);border-style:solid;border-width:1px;word-wrap:break-word"><cod=
e><div><span style=3D"color:#000">f32_trap_t<br>f64_trap_t</span></div></co=
de></div><div><font face=3D"arial, sans-serif"><br></font></div><div><font =
face=3D"arial, sans-serif">Equivalent to </font><font face=3D"courier new, =
monospace">f32_trap_t</font><font face=3D"arial, sans-serif"> and </font><f=
ont face=3D"courier new, monospace">f64_trap_t</font><font face=3D"arial, s=
ans-serif">, but throw a C++ exception instead of trapping.</font></div><di=
v><font face=3D"arial, sans-serif"><br></font></div><div style=3D"backgroun=
d-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid;b=
order-width:1px;word-wrap:break-word"><code><div><span style=3D"color:#000"=
>f32_throw_t<br>f64_throw_t</span></div></code></div><div><br></div><div><f=
ont face=3D"arial, sans-serif">In addition, implementations may optionally =
provide any or all of the following types for fixed-width binary floating-p=
oint numbers with standardized semantics, =E2=80=A6</font></div><div><font =
face=3D"arial, sans-serif"><br></font></div><div style=3D"background-color:=
rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid;border-wi=
dth:1px;word-wrap:break-word"><code><div><span style=3D"color:#000">f8_t<br=
>f16_t<br>f80_t<br>f128_t<br>f256_t<br>f16_iec559_t<br>f128_iec559_t<br>f25=
6_iec559_t<br>f8_fast_t<br>f16_fast_t<br>f80_fast_t<br>f128_fast_t<br>f256_=
fast_t<br>f8_trap_t<br>f16_trap_t<br>f80_trap_t<br>f128_trap_t<br>f256_trap=
_t<br>f8_throw_t<br>f16_throw_t<br>f80_throw_t<br>f128_throw_t<br>f256_thro=
w_t</span></div></code></div><div><br></div><div><font face=3D"arial, sans-=
serif">=E2=80=A6 and may also optionally provide any or all of the followin=
g types for fixed-width decimal floating-point numbers with standardized se=
mantics.</font></div><div><font face=3D"arial, sans-serif"><br></font></div=
><div style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,1=
87);border-style:solid;border-width:1px;word-wrap:break-word"><code><div><s=
pan style=3D"color:#000">dec32_t<br>dec64_t<br>dec128_t<br>dec32_iec559_t<b=
r>dec64_iec559_t<br>dec128_iec559_t<br>dec32_fast_t<br>dec64_fast_t<br>dec1=
28_fast_t<br>dec32_trap_t<br>dec64_trap_t<br>dec128_trap_t<br>dec32_throw_t=
<br>dec64_throw_t<br>dec128_throw_t</span></div></code></div></div></div></=
blockquote><div>=C2=A0<br>GCC7 (in C mode) has support for _Float32, etc ba=
sed on ISO/IEC TS 18661-3:2015. You may want to discuss the relation with t=
hat TS in your proposal.<br><br>https://gcc.gnu.org/ml/gcc-patches/2016-08/=
msg01290.html<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/47e6dde8-9ff5-4950-b385-029b9f81fe62%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/47e6dde8-9ff5-4950-b385-029b9f81fe62=
%40isocpp.org</a>.<br />

------=_Part_515_1355129295.1488044689136--

------=_Part_514_479166942.1488044689135--

.