Topic: Trait for arithmetic types similar to
Author: Manuel Bergler <berglerma@gmail.com>
Date: Wed, 26 Jul 2017 18:14:20 +0200
Raw View
--001a113db9a09a292805553abd07
Content-Type: text/plain; charset="UTF-8"
Hi everyone,
I recently came across an easily fixed issue with the <random>
distributions producing real values (in my particular case
std::normal_distribution): While all of these have a template parameter to
allow for different floating point types, they are specified in terms of
std::is_floating_point - which users are not allowed to specialize.
This makes it cumbersome to use it with custom arithmetic types. In my case
I needed a random std::chrono::duration<double, std::milli>.
Due to the limitation on types satisfying std::is_floating_point you can't
just create a std::normal_distribution<std::chrono::duration<double,
std::milli>>, but instead first have to get the counts for the mean and the
standard deviation out of existing std::chrono::duration<double,
std::milli> objects out, create a distribution using these values, and
finally pack the value obtained by using its operator() back into a
std::chrono::duration object at every site that uses the distribution.
However, allowing only float, double or long double is not a restriction of
the implementation (at least in the libstdc++ one I tested). As a matter of
fact, just specializing std::is_floating_point for std::chrono::duration -
even though it is not allowed and thus undefined behaviour - makes
````
using milliseconds_d = std::chrono::duration<double, std::milli>;
std::normal_distribution<milliseconds_d> distribution{milliseconds_d{0},
milliseconds_d{1}};
````
compile and the distribution yields the exact same values as it does for
pure doubles.
So I was wondering where else in the library these restrictions are kind of
arbitrary and if it does make sense to use something like
std::chrono::treat_as_floating point in other places of the library.
But before searching in all of the STL for components that are
unnecessarily restrictive I first wanted to ask for feedback.
In light of the work on the Numerics TS as outlined in [P0101r0], which
will introduce more arithmetic types to the standard library I think it
definitely makes sense to make all kinds of STL components aware of
user-defined arithmetic types, but what is your opinion?
Best regards
Manuel
[P0101r0]
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0101r0.html
--
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/CAM76qmvf09dHUx6-9sui_XAA6amObKUjcp_DrEsHXRAJ1qu5pA%40mail.gmail.com.
--001a113db9a09a292805553abd07
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi everyone,<div><br></div><div>I recently came across an =
easily fixed issue with the <random> distributions producing real val=
ues (in my particular case std::normal_distribution): While all of these ha=
ve a template parameter to allow for different floating point types, they a=
re specified in terms of std::is_floating_point - which users are not allow=
ed to specialize.</div><div><br></div><div>This makes it cumbersome to use =
it with custom arithmetic types. In my case I needed a random std::chrono::=
duration<double, std::milli>.=C2=A0</div><div><br></div><div>Due to t=
he limitation on types satisfying std::is_floating_point you can't just=
create a std::normal_distribution<std::<wbr>chrono::duration<double,=
std::milli>>, but instead first have to get the counts for the mean =
and the standard deviation out of existing std::chrono::duration<double,=
std::milli> objects out, create a distribution using these values, and =
finally pack the value obtained by using its operator() back into a std::ch=
rono::duration object at every site that uses the distribution.</div><div><=
br></div><div>However, allowing only float, double or long double is not a =
restriction of the implementation (at least in the libstdc++ one I tested).=
As a matter of fact, just specializing std::is_floating_point for std::chr=
ono::duration - even though it is not allowed and thus undefined behaviour =
- makes=C2=A0</div><div>=C2=A0 =C2=A0</div><div>=C2=A0 =C2=A0 ````<br>=C2=
=A0 =C2=A0 using milliseconds_d =3D std::chrono::duration<double, std::m=
illi>;</div><div>=C2=A0 =C2=A0 std::normal_distribution<milli<wbr>sec=
onds_d> distribution{milliseconds_d{0}<wbr>, milliseconds_d{1}};</div><d=
iv>=C2=A0 =C2=A0 ````</div><div><br></div><div>compile and the distribution=
yields the exact same values as it does for pure doubles.</div><div><br></=
div><div>So I was wondering where else in the library these restrictions ar=
e kind of arbitrary and if it does make sense to use something like std::ch=
rono::treat_as_floating point in other places of the library.</div><div>But=
before searching in all of the STL for components that are unnecessarily r=
estrictive I first wanted to ask for feedback.</div><div><br></div><div>In =
light of the work on the Numerics TS as outlined in [P0101r0], which will i=
ntroduce more arithmetic types to the standard library I think it definitel=
y makes sense to make all kinds of STL components aware of user-defined ari=
thmetic types, but what is your opinion?</div><div><br></div><div>Best rega=
rds</div><div>Manuel =C2=A0</div><div><br></div><div><br></div><div>[P0101r=
0] <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0101=
r0.html">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0101r0.ht=
ml</a></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/CAM76qmvf09dHUx6-9sui_XAA6amObKUjcp_D=
rEsHXRAJ1qu5pA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAM76qmvf09dHUx6-=
9sui_XAA6amObKUjcp_DrEsHXRAJ1qu5pA%40mail.gmail.com</a>.<br />
--001a113db9a09a292805553abd07--
.
Author: John McFarlane <john@mcfarlane.name>
Date: Wed, 26 Jul 2017 18:02:57 +0000
Raw View
--001a11477fd2abfea405553c4200
Content-Type: text/plain; charset="UTF-8"
On Wed, Jul 26, 2017 at 9:14 AM Manuel Bergler <berglerma@gmail.com> wrote:
> Hi everyone,
>
Hi Manual
However, allowing only float, double or long double is not a restriction of
> the implementation (at least in the libstdc++ one I tested). As a matter of
> fact, just specializing std::is_floating_point for std::chrono::duration -
> even though it is not allowed and thus undefined behaviour - makes
>
> ````
> using milliseconds_d = std::chrono::duration<double, std::milli>;
> std::normal_distribution<milliseconds_d>
> distribution{milliseconds_d{0}, milliseconds_d{1}};
> ````
>
> compile and the distribution yields the exact same values as it does for
> pure doubles.
>
I'm sure that you're aware that it's a very big leap from not observing any
UB in one implementation to writing code that is safe. But you might be
surprised by what implementors do with the assumptions you are breaking!
So I was wondering where else in the library these restrictions are kind of
> arbitrary and if it does make sense to use something like
> std::chrono::treat_as_floating point in other places of the library.
>
I would not say that they are arbitrary. It's easy to start with tight
restrictions that allow basic functionality and relax them in future
revisions. But it's much harder to shut the stable door once the horse has
bolted.
> But before searching in all of the STL for components that are
> unnecessarily restrictive I first wanted to ask for feedback.
>
> In light of the work on the Numerics TS as outlined in [P0101r0], which
> will introduce more arithmetic types to the standard library I think it
> definitely makes sense to make all kinds of STL components aware of
> user-defined arithmetic types, but what is your opinion?
>
You might be interested in P0437. It proposes moving the functionality of
`numeric_limits` into individual traits -- like those in <type_traits> --
but continuing to allow specialization for user-defined types. The
specific case of a test for floating-point is deferred but this seems to be
the current approach to achieve what you're after.
There are some tough problems to address here though. Firstly, while
`duration<float>` or the types from P0101 can behave like floating-point
types, that does not mean that either of them are, themselves,
floating-point types. They are essentially classes. So some other
property may be what we're really after here: perhaps the ability to
convert between floating-point types or the ability to approximate real
numbers.
It's difficult to say what these properties are until more types exhibit
them but I hope that there is a way forward here that allows seamless
interoperability between all numeric types where that makes sense.
John
--
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/CABPJVnTsGJmiV3mePzgum4j_BLdcReBDXGjp4kCXCRnFDU8%2BbA%40mail.gmail.com.
--001a11477fd2abfea405553c4200
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Wed, Jul 26=
, 2017 at 9:14 AM Manuel Bergler <<a href=3D"mailto:berglerma@gmail.com"=
>berglerma@gmail.com</a>> wrote:<br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr">Hi everyone,</div></blockquote><div>Hi Manual <br><br></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">However, allowing only f=
loat, double or long double is not a restriction of the implementation (at =
least in the libstdc++ one I tested). As a matter of fact, just specializin=
g std::is_floating_point for std::chrono::duration - even though it is not =
allowed and thus undefined behaviour - makes=C2=A0<div>=C2=A0 =C2=A0</div><=
div>=C2=A0 =C2=A0 ````<br>=C2=A0 =C2=A0 using milliseconds_d =3D std::chron=
o::duration<double, std::milli>;</div><div>=C2=A0 =C2=A0 std::normal_=
distribution<milliseconds_d> distribution{milliseconds_d{0}, millisec=
onds_d{1}};</div><div>=C2=A0 =C2=A0 ````</div><div><br></div><div>compile a=
nd the distribution yields the exact same values as it does for pure double=
s.</div></div></blockquote><div><br></div><div>I'm sure that you're=
aware that it's a very big leap from not observing any UB in one imple=
mentation to writing code that is safe.=C2=A0 But you might be surprised by=
what implementors do with the assumptions you are breaking!<br><br></div><=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
#ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>So I was wondering wher=
e else in the library these restrictions are kind of arbitrary and if it do=
es make sense to use something like std::chrono::treat_as_floating point in=
other places of the library.</div></div></blockquote><div><br>I would not =
say that they are arbitrary.=C2=A0 It's easy to start with tight restri=
ctions that allow basic functionality and relax them in future revisions.=
=C2=A0 But it's much harder to shut the stable door once the horse has =
bolted.<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><div>But before searching in all of the STL for components that ar=
e unnecessarily restrictive I first wanted to ask for feedback.</div><div><=
br></div><div>In light of the work on the Numerics TS as outlined in [P0101=
r0], which will introduce more arithmetic types to the standard library I t=
hink it definitely makes sense to make all kinds of STL components aware of=
user-defined arithmetic types, but what is your opinion?</div></div></bloc=
kquote><div><br></div><div>You might be interested in P0437.=C2=A0 It propo=
ses moving the functionality of `numeric_limits` into individual traits -- =
like those in <type_traits> -- but continuing to allow specialization=
for user-defined types.=C2=A0 The specific case of a test for floating-poi=
nt is deferred but this seems to be the current approach to achieve what yo=
u're after.<br><br></div><div>There are some tough problems to address =
here though.=C2=A0 Firstly, while `duration<float>` or the types from=
P0101 can behave like floating-point types, that does not mean that either=
of them are, themselves, floating-point types.=C2=A0 They are essentially =
classes.=C2=A0 So some other property may be what we're really after he=
re: perhaps the ability to convert between floating-point types or the abil=
ity to approximate real numbers.=C2=A0 <br><br>It's difficult to say wh=
at these properties are until more types exhibit them but I hope that there=
is a way forward here that allows seamless interoperability between all nu=
meric types where that makes sense.<br></div><div>=C2=A0<br></div><div>John=
</div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/CABPJVnTsGJmiV3mePzgum4j_BLdcReBDXGjp=
4kCXCRnFDU8%2BbA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CABPJVnTsGJmiV3=
mePzgum4j_BLdcReBDXGjp4kCXCRnFDU8%2BbA%40mail.gmail.com</a>.<br />
--001a11477fd2abfea405553c4200--
.
Author: Peter Sommerlad <peter.sommerlad@hsr.ch>
Date: Wed, 26 Jul 2017 20:49:00 +0200
Raw View
--Apple-Mail-A9F30C1C-52A9-4A51-B2AE-EAA33E06DA54
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
I believe that discussion must also be done considering a more complete uni=
ts library, beyond just duration. But the problems to address are essential=
ly the same, so what works for duration might be a good starting point for =
generalization.
Thank you both for bringing this up.
Regards
Peter
Sent from Peter Sommerlad's iPad
+41 79 432 23 32
> On 26 Jul 2017, at 20:03, John McFarlane <john@mcfarlane.name> wrote:
>=20
>> On Wed, Jul 26, 2017 at 9:14 AM Manuel Bergler <berglerma@gmail.com> wro=
te:
>> Hi everyone,
> Hi Manual=20
>=20
>> However, allowing only float, double or long double is not a restriction=
of the implementation (at least in the libstdc++ one I tested). As a matte=
r of fact, just specializing std::is_floating_point for std::chrono::durati=
on - even though it is not allowed and thus undefined behaviour - makes=20
>> =20
>> ````
>> using milliseconds_d =3D std::chrono::duration<double, std::milli>;
>> std::normal_distribution<milliseconds_d> distribution{milliseconds_d=
{0}, milliseconds_d{1}};
>> ````
>>=20
>> compile and the distribution yields the exact same values as it does for=
pure doubles.
>=20
> I'm sure that you're aware that it's a very big leap from not observing a=
ny UB in one implementation to writing code that is safe. But you might be=
surprised by what implementors do with the assumptions you are breaking!
>=20
>> So I was wondering where else in the library these restrictions are kind=
of arbitrary and if it does make sense to use something like std::chrono::=
treat_as_floating point in other places of the library.
>=20
> I would not say that they are arbitrary. It's easy to start with tight r=
estrictions that allow basic functionality and relax them in future revisio=
ns. But it's much harder to shut the stable door once the horse has bolted=
..
> =20
>> But before searching in all of the STL for components that are unnecessa=
rily restrictive I first wanted to ask for feedback.
>>=20
>> In light of the work on the Numerics TS as outlined in [P0101r0], which =
will introduce more arithmetic types to the standard library I think it def=
initely makes sense to make all kinds of STL components aware of user-defin=
ed arithmetic types, but what is your opinion?
>=20
> You might be interested in P0437. It proposes moving the functionality o=
f `numeric_limits` into individual traits -- like those in <type_traits> --=
but continuing to allow specialization for user-defined types. The specif=
ic case of a test for floating-point is deferred but this seems to be the c=
urrent approach to achieve what you're after.
>=20
> There are some tough problems to address here though. Firstly, while `du=
ration<float>` or the types from P0101 can behave like floating-point types=
, that does not mean that either of them are, themselves, floating-point ty=
pes. They are essentially classes. So some other property may be what we'=
re really after here: perhaps the ability to convert between floating-point=
types or the ability to approximate real numbers. =20
>=20
> It's difficult to say what these properties are until more types exhibit =
them but I hope that there is a way forward here that allows seamless inter=
operability between all numeric types where that makes sense.
> =20
> John
> --=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=
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/isoc=
pp.org/d/msgid/std-proposals/CABPJVnTsGJmiV3mePzgum4j_BLdcReBDXGjp4kCXCRnFD=
U8%2BbA%40mail.gmail.com.
--=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/4DFE708E-6589-4A08-8A65-766B6CC4C19E%40hsr.ch.
--Apple-Mail-A9F30C1C-52A9-4A51-B2AE-EAA33E06DA54
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=
=3Dutf-8"></head><body dir=3D"auto"><div>I believe that discussion must als=
o be done considering a more complete units library, beyond just duration. =
But the problems to address are essentially the same, so what works for dur=
ation might be a good starting point for generalization.</div><div id=3D"Ap=
pleMailSignature"><br></div><div id=3D"AppleMailSignature">Thank you both f=
or bringing this up.</div><div id=3D"AppleMailSignature"><br></div><div id=
=3D"AppleMailSignature">Regards</div><div id=3D"AppleMailSignature">Peter<b=
r><br>Sent from Peter Sommerlad's<span class=3D"Apple-style-span" style=3D"=
-webkit-tap-highlight-color: rgba(26, 26, 26, 0.296875); -webkit-compositio=
n-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-colo=
r: rgba(77, 128, 180, 0.230469); "> iPad</span><div><span class=3D"App=
le-style-span" style=3D"-webkit-tap-highlight-color: rgba(26, 26, 26, 0.296=
875); -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webki=
t-composition-frame-color: rgba(77, 128, 180, 0.230469); ">+41 79 432 23 32=
</span></div></div><div><br>On 26 Jul 2017, at 20:03, John McFarlane <<a=
href=3D"mailto:john@mcfarlane.name">john@mcfarlane.name</a>> wrote:<br>=
<br></div><blockquote type=3D"cite"><div><meta http-equiv=3D"Content-Type" =
content=3D"text/html; charset=3Dutf-8"><div dir=3D"ltr"><div class=3D"gmail=
_quote"><div dir=3D"ltr">On Wed, Jul 26, 2017 at 9:14 AM Manuel Bergler <=
;<a href=3D"mailto:berglerma@gmail.com">berglerma@gmail.com</a>> wrote:<=
br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Hi everyone,</div>=
</blockquote><div>Hi Manual <br><br></div><blockquote class=3D"gmail_quote"=
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv dir=3D"ltr">However, allowing only float, double or long double is not a=
restriction of the implementation (at least in the libstdc++ one I tested)=
.. As a matter of fact, just specializing std::is_floating_point for std::ch=
rono::duration - even though it is not allowed and thus undefined behaviour=
- makes <div> </div><div> ````<br> &nb=
sp; using milliseconds_d =3D std::chrono::duration<double, std::milli>=
;;</div><div> std::normal_distribution<milliseconds_d> d=
istribution{milliseconds_d{0}, milliseconds_d{1}};</div><div> =
````</div><div><br></div><div>compile and the distribution yields the exact=
same values as it does for pure doubles.</div></div></blockquote><div><br>=
</div><div>I'm sure that you're aware that it's a very big leap from not ob=
serving any UB in one implementation to writing code that is safe. Bu=
t you might be surprised by what implementors do with the assumptions you a=
re breaking!<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><=
div>So I was wondering where else in the library these restrictions are kin=
d of arbitrary and if it does make sense to use something like std::chrono:=
:treat_as_floating point in other places of the library.</div></div></block=
quote><div><br>I would not say that they are arbitrary. It's easy to =
start with tight restrictions that allow basic functionality and relax them=
in future revisions. But it's much harder to shut the stable door on=
ce the horse has bolted.<br></div><div> </div><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><div dir=3D"ltr"><div>But before searching in all of the STL for com=
ponents that are unnecessarily restrictive I first wanted to ask for feedba=
ck.</div><div><br></div><div>In light of the work on the Numerics TS as out=
lined in [P0101r0], which will introduce more arithmetic types to the stand=
ard library I think it definitely makes sense to make all kinds of STL comp=
onents aware of user-defined arithmetic types, but what is your opinion?</d=
iv></div></blockquote><div><br></div><div>You might be interested in P0437.=
It proposes moving the functionality of `numeric_limits` into indivi=
dual traits -- like those in <type_traits> -- but continuing to allow=
specialization for user-defined types. The specific case of a test f=
or floating-point is deferred but this seems to be the current approach to =
achieve what you're after.<br><br></div><div>There are some tough problems =
to address here though. Firstly, while `duration<float>` or the=
types from P0101 can behave like floating-point types, that does not mean =
that either of them are, themselves, floating-point types. They are e=
ssentially classes. So some other property may be what we're really a=
fter here: perhaps the ability to convert between floating-point types or t=
he ability to approximate real numbers. <br><br>It's difficult to say=
what these properties are until more types exhibit them but I hope that th=
ere is a way forward here that allows seamless interoperability between all=
numeric types where that makes sense.<br></div><div> <br></div><div>J=
ohn</div></div></div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" 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/CABPJVnTsGJmiV3mePzgum4j_BLdcReBDXGjp=
4kCXCRnFDU8%2BbA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CABPJVnTsGJ=
miV3mePzgum4j_BLdcReBDXGjp4kCXCRnFDU8%2BbA%40mail.gmail.com</a>.<br>
</div></blockquote></body></html>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/4DFE708E-6589-4A08-8A65-766B6CC4C19E%=
40hsr.ch?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/4DFE708E-6589-4A08-8A65-766B6CC4C19E%40h=
sr.ch</a>.<br />
--Apple-Mail-A9F30C1C-52A9-4A51-B2AE-EAA33E06DA54--
.
Author: Manuel Bergler <berglerma@gmail.com>
Date: Thu, 27 Jul 2017 01:18:07 +0200
Raw View
--001a11408b7630588c055540a96b
Content-Type: text/plain; charset="UTF-8"
On Wed, Jul 26, 2017 at 8:02 PM, John McFarlane <john@mcfarlane.name> wrote:
> On Wed, Jul 26, 2017 at 9:14 AM Manuel Bergler <berglerma@gmail.com>
> wrote:
>
>> Hi everyone,
>>
> Hi Manual
>
> However, allowing only float, double or long double is not a restriction
>> of the implementation (at least in the libstdc++ one I tested). As a matter
>> of fact, just specializing std::is_floating_point for std::chrono::duration
>> - even though it is not allowed and thus undefined behaviour - makes
>>
>> ````
>> using milliseconds_d = std::chrono::duration<double, std::milli>;
>> std::normal_distribution<milliseconds_d>
>> distribution{milliseconds_d{0}, milliseconds_d{1}};
>> ````
>>
>> compile and the distribution yields the exact same values as it does for
>> pure doubles.
>>
>
> I'm sure that you're aware that it's a very big leap from not observing
> any UB in one implementation to writing code that is safe. But you might
> be surprised by what implementors do with the assumptions you are breaking!
>
Yes, I'm aware of that. But from a purely conceptual standpoint there is
nothing that speaks against drawing milliseconds distributed according to a
normal distribution, so I suspected that the mathematical formula
underlying the implementation should also work for milliseconds - as it
does in the case of libstdc++. But of course you're right that some
optimizations that implementors might use could potentially break it. But
then the more fundamental question becomes: Is it desirable to have it work
for other arithmetic types. If some of the optimizations cannot be applied
in the more general setting there always is the possibility for the
implementors to specialize the template for these.
>
> So I was wondering where else in the library these restrictions are kind
>> of arbitrary and if it does make sense to use something like
>> std::chrono::treat_as_floating point in other places of the library.
>>
>
> I would not say that they are arbitrary. It's easy to start with tight
> restrictions that allow basic functionality and relax them in future
> revisions. But it's much harder to shut the stable door once the horse has
> bolted.
>
This is a good point. But now that e.g. the distributions have been
implemented we can get implementors feedback if these restrictions are
actually used and how much of a hassle it would be to lift them.
>
>
>> But before searching in all of the STL for components that are
>> unnecessarily restrictive I first wanted to ask for feedback.
>>
>> In light of the work on the Numerics TS as outlined in [P0101r0], which
>> will introduce more arithmetic types to the standard library I think it
>> definitely makes sense to make all kinds of STL components aware of
>> user-defined arithmetic types, but what is your opinion?
>>
>
> You might be interested in P0437. It proposes moving the functionality of
> `numeric_limits` into individual traits -- like those in <type_traits> --
> but continuing to allow specialization for user-defined types. The
> specific case of a test for floating-point is deferred but this seems to be
> the current approach to achieve what you're after.
>
While it would work for the particular combination of std::chrono::duration
and std::normal_distribution, even if we were to decide to add such a
"treat as floating point" trait we need an accompanying concept so that it
is clear what the library expects of a type for which the trait returns
true. Some questions to consider:
- Should we require all operations to be constexpr and/or noexcept?
That would exclude something like Boost.Multiprecision which requires
dynamic allocation or bound-checking wrappers that throw when an overflow
is detected.
- Does the result type of a multiplication of an arithmetic type T with
a built-in floating point type have to be T again? That would exclude
elastic integers and hence rationals built on top of these, but is required
for accumulation.
- Should we require multiplication of a built-in integer type with a
arithmetic floating point type to work? That excludes Boost.Units.
- Do we need implicit conversion back to the built-in type? That
excludes std::chrono::duration with a floating point representation.
>
> There are some tough problems to address here though. Firstly, while
> `duration<float>` or the types from P0101 can behave like floating-point
> types, that does not mean that either of them are, themselves,
> floating-point types. They are essentially classes. So some other
> property may be what we're really after here: perhaps the ability to
> convert between floating-point types or the ability to approximate real
> numbers.
>
>
Thinking about it, maybe we even need a concept hierarchy that describes
how "close" a particular arithmetic type is to built-in floating point
types similar to the iterators hierarchy in order to be able to capture all
cases, otherwise we'll always run into cases that conceptually "should just
work" but don't due to the limitations described above.
It's difficult to say what these properties are until more types exhibit
> them but I hope that there is a way forward here that allows seamless
> interoperability between all numeric types where that makes sense.
>
I agree. Maybe we'll even need the same thing for integral arithmetic types
and then the requirements should be consistent.
>
>
> John
>
> --
> 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/CABPJVnTsGJmiV3mePzgum4j_
> BLdcReBDXGjp4kCXCRnFDU8%2BbA%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CABPJVnTsGJmiV3mePzgum4j_BLdcReBDXGjp4kCXCRnFDU8%2BbA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
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/CAM76qmu3xAdoeo4OwBZHMzisHt2%3D8D5-%3Drv9AU0VacxjSEbAGg%40mail.gmail.com.
--001a11408b7630588c055540a96b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Wed, Jul 26, 2017 at 8:02 PM, John McFarlane <span dir=3D"ltr"><<a hr=
ef=3D"mailto:john@mcfarlane.name" target=3D"_blank">john@mcfarlane.name</a>=
></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px=
0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><di=
v dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Wed, Jul 26, 2=
017 at 9:14 AM Manuel Bergler <<a href=3D"mailto:berglerma@gmail.com" ta=
rget=3D"_blank">berglerma@gmail.com</a>> wrote:<br></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid =
rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">Hi everyone,</div></blo=
ckquote><div>Hi Manual <br><br></div><span class=3D"gmail-"><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid =
rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">However, allowing only =
float, double or long double is not a restriction of the implementation (at=
least in the libstdc++ one I tested). As a matter of fact, just specializi=
ng std::is_floating_point for std::chrono::duration - even though it is not=
allowed and thus undefined behaviour - makes=C2=A0<div>=C2=A0 =C2=A0</div>=
<div>=C2=A0 =C2=A0 ````<br>=C2=A0 =C2=A0 using milliseconds_d =3D std::chro=
no::duration<double, std::milli>;</div><div>=C2=A0 =C2=A0 std::normal=
_distribution<<wbr>milliseconds_d> distribution{milliseconds_d{0}<wbr=
>, milliseconds_d{1}};</div><div>=C2=A0 =C2=A0 ````</div><div><br></div><di=
v>compile and the distribution yields the exact same values as it does for =
pure doubles.</div></div></blockquote><div><br></div></span><div>I'm su=
re that you're aware that it's a very big leap from not observing a=
ny UB in one implementation to writing code that is safe.=C2=A0 But you mig=
ht be surprised by what implementors do with the assumptions you are breaki=
ng!<br></div></div></div></blockquote><div><br></div><div>Yes, I'm awar=
e of that. But from a purely conceptual standpoint there is nothing that sp=
eaks against drawing milliseconds distributed according to a normal distrib=
ution, so I suspected that the mathematical formula underlying the implemen=
tation should also work for milliseconds - as it does in the case of libstd=
c++. But of course you're right that some optimizations that implemento=
rs might use could potentially break it. But then the more fundamental ques=
tion becomes: Is it desirable to have it work for other arithmetic types. I=
f some of the optimizations cannot be applied in the more general setting t=
here always is the possibility for the implementors to specialize the templ=
ate for these.</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div =
dir=3D"ltr"><div class=3D"gmail_quote"><div><br></div><span class=3D"gmail-=
"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>S=
o I was wondering where else in the library these restrictions are kind of =
arbitrary and if it does make sense to use something like std::chrono::trea=
t_as_floating point in other places of the library.</div></div></blockquote=
></span><div><br>I would not say that they are arbitrary.=C2=A0 It's ea=
sy to start with tight restrictions that allow basic functionality and rela=
x them in future revisions.=C2=A0 But it's much harder to shut the stab=
le door once the horse has bolted.<br></div></div></div></blockquote><div><=
br></div><div>This is a good point. But now that e.g. the distributions hav=
e been implemented we can get implementors feedback if these restrictions a=
re actually used and how much of a hassle it would be to lift them.</div><d=
iv>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div d=
ir=3D"ltr"><div class=3D"gmail_quote"><div></div><span class=3D"gmail-"><di=
v>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D=
"ltr"><div>But before searching in all of the STL for components that are u=
nnecessarily restrictive I first wanted to ask for feedback.</div><div><br>=
</div><div>In light of the work on the Numerics TS as outlined in [P0101r0]=
, which will introduce more arithmetic types to the standard library I thin=
k it definitely makes sense to make all kinds of STL components aware of us=
er-defined arithmetic types, but what is your opinion?</div></div></blockqu=
ote><div><br></div></span><div>You might be interested in P0437.=C2=A0 It p=
roposes moving the functionality of `numeric_limits` into individual traits=
-- like those in <type_traits> -- but continuing to allow specializa=
tion for user-defined types.=C2=A0 The specific case of a test for floating=
-point is deferred but this seems to be the current approach to achieve wha=
t you're after.<br></div></div></div></blockquote><div><br></div><div>W=
hile it would work for the particular combination of std::chrono::duration =
and std::normal_distribution, even if we were to decide to add such a "=
;treat as floating point" trait we need an accompanying concept so tha=
t it is clear what the library expects of a type for which the trait return=
s true.=C2=A0 Some questions to consider:</div><div><div>=C2=A0 =C2=A0 =C2=
=A0- Should we require all operations to be constexpr and/or noexcept? That=
would exclude something like Boost.Multiprecision which requires dynamic a=
llocation or bound-checking wrappers that throw when an overflow is detecte=
d.</div><div>=C2=A0 =C2=A0 - Does the result type of a multiplication of an=
arithmetic type T with a built-in floating point type have to be T again? =
That would exclude elastic integers and hence rationals built on top of the=
se, but is required for accumulation.</div></div><div>=C2=A0 =C2=A0- Should=
we require multiplication of a built-in integer type with a arithmetic flo=
ating point type to work? That excludes Boost.Units.</div><div>=C2=A0 =C2=
=A0- Do we need implicit conversion back to the built-in type? That exclude=
s std::chrono::duration with a floating point representation.</div><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"=
><div class=3D"gmail_quote"><div><br></div><div>There are some tough proble=
ms to address here though.=C2=A0 Firstly, while `duration<float>` or =
the types from P0101 can behave like floating-point types, that does not me=
an that either of them are, themselves, floating-point types.=C2=A0 They ar=
e essentially classes.=C2=A0 So some other property may be what we're r=
eally after here: perhaps the ability to convert between floating-point typ=
es or the ability to approximate real numbers.=C2=A0 <br><br></div></div></=
div></blockquote><div><br></div><div>Thinking about it, maybe we even need =
a concept hierarchy that describes how "close" a particular arith=
metic type is to built-in floating point types similar to the iterators hie=
rarchy in order to be able to capture all cases, otherwise we'll always=
run into cases that conceptually "should just work" but don'=
t due to the limitations described above.</div><div><br></div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px soli=
d rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_q=
uote"><div>It's difficult to say what these properties are until more t=
ypes exhibit them but I hope that there is a way forward here that allows s=
eamless interoperability between all numeric types where that makes sense.<=
/div></div></div></blockquote><div><br></div><div>I agree. Maybe we'll =
even need the same thing for integral arithmetic types and then the require=
ments should be consistent.=C2=A0</div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padd=
ing-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><div><span class=
=3D"gmail-HOEnZb"><font color=3D"#888888"><br></font></span></div><span cla=
ss=3D"gmail-HOEnZb"><font color=3D"#888888"><div>=C2=A0<br></div><div>John<=
/div></font></span></div></div><span class=3D"gmail-HOEnZb"><font color=3D"=
#888888">
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">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/CABPJVnTsGJmiV3mePzgum4j_BLdcReBDXGjp=
4kCXCRnFDU8%2BbA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/st=
d-<wbr>proposals/<wbr>CABPJVnTsGJmiV3mePzgum4j_<wbr>BLdcReBDXGjp4kCXCRnFDU8=
%2BbA%<wbr>40mail.gmail.com</a>.<br>
</font></span></blockquote></div><br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/CAM76qmu3xAdoeo4OwBZHMzisHt2%3D8D5-%3=
Drv9AU0VacxjSEbAGg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAM76qmu3xAdo=
eo4OwBZHMzisHt2%3D8D5-%3Drv9AU0VacxjSEbAGg%40mail.gmail.com</a>.<br />
--001a11408b7630588c055540a96b--
.
Author: John McFarlane <john@mcfarlane.name>
Date: Thu, 27 Jul 2017 01:16:41 +0000
Raw View
--001a11472a56d8f89c055542512a
Content-Type: text/plain; charset="UTF-8"
On Wed, Jul 26, 2017 at 4:18 PM Manuel Bergler <berglerma@gmail.com> wrote:
> On Wed, Jul 26, 2017 at 8:02 PM, John McFarlane <john@mcfarlane.name>
> wrote:
>
>> On Wed, Jul 26, 2017 at 9:14 AM Manuel Bergler <berglerma@gmail.com>
>> wrote:
>>
>>> In light of the work on the Numerics TS as outlined in [P0101r0], which
>>> will introduce more arithmetic types to the standard library I think it
>>> definitely makes sense to make all kinds of STL components aware of
>>> user-defined arithmetic types, but what is your opinion?
>>>
>>
>> You might be interested in P0437. It proposes moving the functionality
>> of `numeric_limits` into individual traits -- like those in <type_traits>
>> -- but continuing to allow specialization for user-defined types. The
>> specific case of a test for floating-point is deferred but this seems to be
>> the current approach to achieve what you're after.
>>
>
> While it would work for the particular combination of
> std::chrono::duration and std::normal_distribution, even if we were to
> decide to add such a "treat as floating point" trait we need an
> accompanying concept so that it is clear what the library expects of a type
> for which the trait returns true. Some questions to consider:
> - Should we require all operations to be constexpr and/or noexcept?
> That would exclude something like Boost.Multiprecision which requires
> dynamic allocation or bound-checking wrappers that throw when an overflow
> is detected.
>
I've not found these to be a major issue. The same literal type
instantiated with `Boost.Multiprecision` becomes no longer literal but
continues to work well in run-time expressions. As for `noexcept`, one has
to provide an expression to the `noexcept` specifier which typically
replicates the body of the function. This is unfortunate but I believe
that it can be added to an existing interface without breaking it.
- Does the result type of a multiplication of an arithmetic type T with
> a built-in floating point type have to be T again? That would exclude
> elastic integers and hence rationals built on top of these, but is required
> for accumulation.
>
Generally no. It's really up to the wrapping class -- in this case
`duration`. Doesn't this also exclude `int`?
> - Should we require multiplication of a built-in integer type with a
> arithmetic floating point type to work? That excludes Boost.Units.
>
I don't really have enough experience of Boost.Units to comment other than
to say it has some pretty obvious restrictions. An example might help.
> - Do we need implicit conversion back to the built-in type? That
> excludes std::chrono::duration with a floating point representation.
>
Again, it depends. Units, is a great example of where implicit conversions
are typically a big no-no. Many 'safe' types are also. But for a wrapper
that is trying to be agnostic about what it is wrapping, I believe it
should generally match with whatever the behavior of the wrapped type is,
i.e. if `T` allows implicit conversion, then `Wrapper<T>` should seriously
consider allowing implicit conversion also.
>
>
>>
>> There are some tough problems to address here though. Firstly, while
>> `duration<float>` or the types from P0101 can behave like floating-point
>> types, that does not mean that either of them are, themselves,
>> floating-point types. They are essentially classes. So some other
>> property may be what we're really after here: perhaps the ability to
>> convert between floating-point types or the ability to approximate real
>> numbers.
>>
>>
> Thinking about it, maybe we even need a concept hierarchy that describes
> how "close" a particular arithmetic type is to built-in floating point
> types similar to the iterators hierarchy in order to be able to capture all
> cases, otherwise we'll always run into cases that conceptually "should just
> work" but don't due to the limitations described above.
>
I'm not at all clear about whether it is possible or wise to conceptify
numeric types. It may be that individual operations/member functions of
outer types such as `duration` need to stipulate quite specific
requirements on a case-by-case basis.
John
--
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/CABPJVnQBg5ZBV2U-i7e4pNMJYkgJNyijWmps-58aAVZK%2BS-%2BeA%40mail.gmail.com.
--001a11472a56d8f89c055542512a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Wed, Jul 26=
, 2017 at 4:18 PM Manuel Bergler <<a href=3D"mailto:berglerma@gmail.com"=
target=3D"_blank">berglerma@gmail.com</a>> wrote:<br></div><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=
=3D"gmail_quote">On Wed, Jul 26, 2017 at 8:02 PM, John McFarlane <span dir=
=3D"ltr"><<a href=3D"mailto:john@mcfarlane.name" target=3D"_blank">john@=
mcfarlane.name</a>></span> wrote:<br><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pad=
ding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr"=
>On Wed, Jul 26, 2017 at 9:14 AM Manuel Bergler <<a href=3D"mailto:bergl=
erma@gmail.com" target=3D"_blank">berglerma@gmail.com</a>> wrote:<br></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">In li=
ght of the work on the Numerics TS as outlined in [P0101r0], which will int=
roduce more arithmetic types to the standard library I think it definitely =
makes sense to make all kinds of STL components aware of user-defined arith=
metic types, but what is your opinion?<br></div></blockquote></div></div></=
blockquote></div></div></div><div dir=3D"ltr"><div class=3D"gmail_extra"><d=
iv class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">=
<div dir=3D"ltr"><div class=3D"gmail_quote"><span class=3D"m_-8834392508368=
903056m_7621087852796927590gmail-"><div><br></div></span><div>You might be =
interested in P0437.=C2=A0 It proposes moving the functionality of `numeric=
_limits` into individual traits -- like those in <type_traits> -- but=
continuing to allow specialization for user-defined types.=C2=A0 The speci=
fic case of a test for floating-point is deferred but this seems to be the =
current approach to achieve what you're after.<br></div></div></div></b=
lockquote><div><br></div></div></div></div><div dir=3D"ltr"><div class=3D"g=
mail_extra"><div class=3D"gmail_quote"><div>While it would work for the par=
ticular combination of std::chrono::duration and std::normal_distribution, =
even if we were to decide to add such a "treat as floating point"=
trait we need an accompanying concept so that it is clear what the library=
expects of a type for which the trait returns true.=C2=A0 Some questions t=
o consider:</div><div><div>=C2=A0 =C2=A0 =C2=A0- Should we require all oper=
ations to be constexpr and/or noexcept? That would exclude something like B=
oost.Multiprecision which requires dynamic allocation or bound-checking wra=
ppers that throw when an overflow is detected.</div></div></div></div></div=
></blockquote><div><br></div><div>I've not found these to be a major is=
sue.=C2=A0 The same literal type instantiated with `Boost.Multiprecision` b=
ecomes no longer literal but continues to work well in run-time expressions=
..=C2=A0 As for `noexcept`, one has to provide an expression to the `noexcep=
t` specifier which typically replicates the body of the function.=C2=A0 Thi=
s is unfortunate but I believe that it can be added to an existing interfac=
e without breaking it.</div><div><br></div><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><=
div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div>=
<div>=C2=A0 =C2=A0 - Does the result type of a multiplication of an arithme=
tic type T with a built-in floating point type have to be T again? That wou=
ld exclude elastic integers and hence rationals built on top of these, but =
is required for accumulation.</div></div></div></div></div></blockquote><di=
v><br></div><div>Generally no.=C2=A0 It's really up to the wrapping cla=
ss -- in this case `duration`.=C2=A0 Doesn't this also exclude `int`? =
=C2=A0</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div>=C2=A0 =C2=A0-=
Should we require multiplication of a built-in integer type with a arithme=
tic floating point type to work? That excludes Boost.Units.</div></div></di=
v></div></blockquote><div><br></div><div>I don't really have enough exp=
erience of Boost.Units to comment other than to say it has some pretty obvi=
ous restrictions.=C2=A0 An example might help.</div><div>=C2=A0</div><block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div c=
lass=3D"gmail_quote"><div>=C2=A0 =C2=A0- Do we need implicit conversion bac=
k to the built-in type? That excludes std::chrono::duration with a floating=
point representation.</div></div></div></div></blockquote><div><br></div><=
div>Again, it depends.=C2=A0 Units, is a great example of where implicit co=
nversions are typically a big no-no.=C2=A0 Many 'safe' types are al=
so.=C2=A0 But for a wrapper that is trying to be agnostic about what it is =
wrapping, I believe it should generally match with whatever the behavior of=
the wrapped type is, i.e. if `T` allows implicit conversion, then `Wrapper=
<T>` should seriously consider allowing implicit conversion also.</di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra=
"><div class=3D"gmail_quote"><div>=C2=A0</div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,20=
4);padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><div><br><=
/div><div>There are some tough problems to address here though.=C2=A0 First=
ly, while `duration<float>` or the types from P0101 can behave like f=
loating-point types, that does not mean that either of them are, themselves=
, floating-point types.=C2=A0 They are essentially classes.=C2=A0 So some o=
ther property may be what we're really after here: perhaps the ability =
to convert between floating-point types or the ability to approximate real =
numbers.=C2=A0 <br><br></div></div></div></blockquote><div><br></div></div>=
</div></div><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail=
_quote"><div>Thinking about it, maybe we even need a concept hierarchy that=
describes how "close" a particular arithmetic type is to built-i=
n floating point types similar to the iterators hierarchy in order to be ab=
le to capture all cases, otherwise we'll always run into cases that con=
ceptually "should just work" but don't due to the limitations=
described above.</div></div></div></div></blockquote><div><br></div><div>I=
'm not at all clear about whether it is possible or wise to conceptify =
numeric types.=C2=A0 It may be that individual operations/member functions =
of outer types such as `duration` need to stipulate quite specific requirem=
ents on a case-by-case basis.=C2=A0</div><div>John</div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/CABPJVnQBg5ZBV2U-i7e4pNMJYkgJNyijWmps=
-58aAVZK%2BS-%2BeA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CABPJVnQBg5ZB=
V2U-i7e4pNMJYkgJNyijWmps-58aAVZK%2BS-%2BeA%40mail.gmail.com</a>.<br />
--001a11472a56d8f89c055542512a--
.