In a recent test I was doing about using constexpr for generating
compile-time tables, I discovered that expressions like this:

 constexpr auto pi = 4 * std::atan(1);

are accepted by gcc, but not by clang.  It seems that the standards
don't require functions like std::atan, std::sin, etc., to be constexpr.
 In the context of embedded systems, being able to make compile-time
tables of things like sin functions can be an extremely useful feature.

Is there any reason why this could not be supported in the C++ standards?


--
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/or7mnd%24fr2%241%40blaine.gmane.org.

.

------=_Part_1370_791738875.1507304888111
Content-Type: multipart/alternative;
 boundary="----=_Part_1371_958216773.1507304888111"

------=_Part_1371_958216773.1507304888111
Content-Type: text/plain; charset="UTF-8"


>
>
> Is there any reason why this could not be supported in the C++ standards?
>
> Breaks compatibility with C I would imagine.

Niall

--
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/01e6fcdd-3250-4017-b53a-cea48f869817%40isocpp.org.

------=_Part_1371_958216773.1507304888111
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br>Is there =
any reason why this could not be supported in the C++ standards?
<br><br></blockquote><div>Breaks compatibility with C I would imagine.</div=
><div><br></div><div>Niall=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/01e6fcdd-3250-4017-b53a-cea48f869817%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/01e6fcdd-3250-4017-b53a-cea48f869817=
%40isocpp.org</a>.<br />

------=_Part_1371_958216773.1507304888111--

------=_Part_1370_791738875.1507304888111--

.

------=_Part_1431_589027928.1507306720916
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I am not sure but exception handling, altering global variable and dynamicl=
y create variables could be other reasons. I do not think that there is any=
thing in the standard that prevents calulated results from being stored in =
a static lookup table. Although I could be wrong.

--=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/d226f4cc-3056-4ca0-96d9-55cd488a2c1d%40isocpp.or=
g.

------=_Part_1431_589027928.1507306720916--

.

On 10/06/2017 12:43 PM, David Brown wrote:
> In a recent test I was doing about using constexpr for generating
> compile-time tables, I discovered that expressions like this:
>
>  constexpr auto pi = 4 * std::atan(1);
>
> are accepted by gcc, but not by clang.  It seems that the standards
> don't require functions like std::atan, std::sin, etc., to be constexpr.
>  In the context of embedded systems, being able to make compile-time
> tables of things like sin functions can be an extremely useful feature.
>
> Is there any reason why this could not be supported in the C++ standards?

Some of these math functions are required to set errno for domain
errors.  All of these math functions should consider the rounding
mode, which is essentially a thread-local variable.

Either fact prevents math functions from being "constexpr".

Yes, a purely functional approach to math functions (no global
state) would be nice to have.  Proposals welcome.

Jens

--
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/59D7C5A7.9060700%40gmx.net.

.

On 6 October 2017 at 21:04, Jens Maurer <Jens.Maurer@gmx.net> wrote:
> On 10/06/2017 12:43 PM, David Brown wrote:
>> In a recent test I was doing about using constexpr for generating
>> compile-time tables, I discovered that expressions like this:
>>
>>       constexpr auto pi = 4 * std::atan(1);
>>
>> are accepted by gcc, but not by clang.  It seems that the standards
>> don't require functions like std::atan, std::sin, etc., to be constexpr.
>>  In the context of embedded systems, being able to make compile-time
>> tables of things like sin functions can be an extremely useful feature.
>>
>> Is there any reason why this could not be supported in the C++ standards?
>
> Some of these math functions are required to set errno for domain
> errors.  All of these math functions should consider the rounding
> mode, which is essentially a thread-local variable.
>
> Either fact prevents math functions from being "constexpr".
>
> Yes, a purely functional approach to math functions (no global
> state) would be nice to have.  Proposals welcome.


Additionally, vectorized implementations don't (yet) work with
constexpr, so we want to avoid
pessimizing implementations just to make them constexpr. And due to
portability concerns, the
standard doesn't allow an implementation to make something constexpr
if it hasn't been so specified.

There's ongoing work to fix some or all of those problems, so there's hope.

--
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/CAFk2RUaJtOFLDMPKCDqoFPdAjx3GDjxUoaDwS0zJYCE25GBVyw%40mail.gmail.com.

.

------=_Part_1938_394931646.1507323733590
Content-Type: multipart/alternative;
 boundary="----=_Part_1939_117967111.1507323733591"

------=_Part_1939_117967111.1507323733591
Content-Type: text/plain; charset="UTF-8"

On Friday, October 6, 2017 at 11:32:36 AM UTC-7, Ville Voutilainen wrote:
>
> Additionally, vectorized implementations don't (yet) work with
> constexpr, so we want to avoid
> pessimizing implementations just to make them constexpr. And due to
> portability concerns, the
> standard doesn't allow an implementation to make something constexpr
> if it hasn't been so specified.
>
> There's ongoing work to fix some or all of those problems, so there's
> hope.
>

This is one reason to allow overloading on constexpr parameters.  It allows
things like separating compile-time and runtime implementations.

Melissa

--
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/fd7be9f0-665b-4917-9af8-219c218e6a52%40isocpp.org.

------=_Part_1939_117967111.1507323733591
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Friday, October 6, 2017 at 11:32:36 AM UTC-7, Ville Vou=
tilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Additionally, v=
ectorized implementations don&#39;t (yet) work with
<br>constexpr, so we want to avoid
<br>pessimizing implementations just to make them constexpr. And due to
<br>portability concerns, the
<br>standard doesn&#39;t allow an implementation to make something constexp=
r
<br>if it hasn&#39;t been so specified.
<br>
<br>There&#39;s ongoing work to fix some or all of those problems, so there=
&#39;s hope.
<br></blockquote><div><br></div><div>This is one reason to allow overloadin=
g on constexpr parameters.=C2=A0 It allows things like separating compile-t=
ime and runtime implementations.</div><div><br></div><div>Melissa<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/fd7be9f0-665b-4917-9af8-219c218e6a52%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/fd7be9f0-665b-4917-9af8-219c218e6a52=
%40isocpp.org</a>.<br />

------=_Part_1939_117967111.1507323733591--

------=_Part_1938_394931646.1507323733590--

.

On 7 October 2017 at 00:02, Myriachan <myriachan@gmail.com> wrote:
> On Friday, October 6, 2017 at 11:32:36 AM UTC-7, Ville Voutilainen wrote:
>>
>> Additionally, vectorized implementations don't (yet) work with
>> constexpr, so we want to avoid
>> pessimizing implementations just to make them constexpr. And due to
>> portability concerns, the
>> standard doesn't allow an implementation to make something constexpr
>> if it hasn't been so specified.
>>
>> There's ongoing work to fix some or all of those problems, so there's
>> hope.
>
>
> This is one reason to allow overloading on constexpr parameters.  It allows
> things like separating compile-time and runtime implementations.


There are other possible solutions than overloading on constexpr. This
paper http://open-std.org/JTC1/SC22/WG21/docs/papers/2017/p0595r0.html
shows one of them.

--
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/CAFk2RUYezuRnT1hbUtP21xKw_JaXJsy%3DjTgRzRBTd7Cwr_okOQ%40mail.gmail.com.

.

------=_Part_2084_1487662093.1507329898805
Content-Type: multipart/alternative;
 boundary="----=_Part_2085_48323886.1507329898805"

------=_Part_2085_48323886.1507329898805
Content-Type: text/plain; charset="UTF-8"

On Friday, October 6, 2017 at 2:03:17 PM UTC-7, Ville Voutilainen wrote:
>
> On 7 October 2017 at 00:02, Myriachan <myri...@gmail.com <javascript:>>
> wrote:
> >
> > This is one reason to allow overloading on constexpr parameters.  It
> allows
> > things like separating compile-time and runtime implementations.
>
>
> There are other possible solutions than overloading on constexpr. This
> paper http://open-std.org/JTC1/SC22/WG21/docs/papers/2017/p0595r0.html
> shows one of them.
>

Would also work!

--
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/fcea9062-9094-498e-8b30-98bc9186e85d%40isocpp.org.

------=_Part_2085_48323886.1507329898805
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Friday, October 6, 2017 at 2:03:17 PM UTC-7, Ville Vout=
ilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 7 October 201=
7 at 00:02, Myriachan &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obf=
uscated-mailto=3D"6PA1q_H3AAAJ" rel=3D"nofollow" onmousedown=3D"this.href=
=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascri=
pt:&#39;;return true;">myri...@gmail.com</a>&gt; wrote:
<br>&gt;
<br>&gt; This is one reason to allow overloading on constexpr parameters. =
=C2=A0It allows
<br>&gt; things like separating compile-time and runtime implementations.
<br>
<br>
<br>There are other possible solutions than overloading on constexpr. This
<br>paper <a href=3D"http://open-std.org/JTC1/SC22/WG21/docs/papers/2017/p0=
595r0.html" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&=
#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fopen-std.org%2FJTC1%2FSC22%=
2FWG21%2Fdocs%2Fpapers%2F2017%2Fp0595r0.html\x26sa\x3dD\x26sntz\x3d1\x26usg=
\x3dAFQjCNEfBVWQryz0Icm8stL_BgvC2jFWpQ&#39;;return true;" onclick=3D"this.h=
ref=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fopen-std.org%2FJTC1%=
2FSC22%2FWG21%2Fdocs%2Fpapers%2F2017%2Fp0595r0.html\x26sa\x3dD\x26sntz\x3d1=
\x26usg\x3dAFQjCNEfBVWQryz0Icm8stL_BgvC2jFWpQ&#39;;return true;">http://ope=
n-std.org/JTC1/SC22/<wbr>WG21/docs/papers/2017/p0595r0.<wbr>html</a>
<br>shows one of them.
<br></blockquote><div><br></div><div>Would also work! <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/fcea9062-9094-498e-8b30-98bc9186e85d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/fcea9062-9094-498e-8b30-98bc9186e85d=
%40isocpp.org</a>.<br />

------=_Part_2085_48323886.1507329898805--

------=_Part_2084_1487662093.1507329898805--

.

On 06/10/17 17:48, Niall Douglas wrote:
>
>     Is there any reason why this could not be supported in the C++
>     standards?
>
> Breaks compatibility with C I would imagine.
>

That would be a reasonable (but not great) justification - though I
don't see how it would.  Perhaps errno support would be the problem?

It certainly should not be too difficult for compilers to support a
second set of maths functions (in a separate namespace) with constexpr
declarations.  Most major compilers support these sorts of functions
with builtins and already have support for versions that ignore errno.

--
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/8c572022-0abd-6677-4b50-788651354e1e%40westcontrol.com.

.

------=_Part_3657_537714681.1507417314853
Content-Type: multipart/alternative;
 boundary="----=_Part_3658_1234269762.1507417314853"

------=_Part_3658_1234269762.1507417314853
Content-Type: text/plain; charset="UTF-8"

On Saturday, October 7, 2017 at 1:24:46 AM UTC+1, David Brown wrote:
>
>
> On 06/10/17 17:48, Niall Douglas wrote:
> >
> >     Is there any reason why this could not be supported in the C++
> >     standards?
> >
> > Breaks compatibility with C I would imagine.
> >
>
> That would be a reasonable (but not great) justification - though I
> don't see how it would.  Perhaps errno support would be the problem?
>

It's not even that.

A very common use case for C++ is to compile straight-C programs for the
improved optimisation.

Thus a C program must run exactly the same in C++ as it would in C. Making
the cmath functions go constexpr in C++ breaks that, badly.

Niall

--
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/79697376-5ccd-470a-b197-ab717ae1d64a%40isocpp.org.

------=_Part_3658_1234269762.1507417314853
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Saturday, October 7, 2017 at 1:24:46 AM UTC+1, David Br=
own wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>On 06/10/17 17:48, Niall Douglas wrote:
<br>&gt;=20
<br>&gt; =C2=A0 =C2=A0 Is there any reason why this could not be supported =
in the C++
<br>&gt; =C2=A0 =C2=A0 standards?
<br>&gt;=20
<br>&gt; Breaks compatibility with C I would imagine.
<br>&gt;=20
<br>
<br>That would be a reasonable (but not great) justification - though I=20
<br>don&#39;t see how it would. =C2=A0Perhaps errno support would be the pr=
oblem?
<br></blockquote><div><br></div><div>It&#39;s not even that.</div><div><br>=
</div><div>A very common use case for C++ is to compile straight-C programs=
 for the improved optimisation.</div><div><br></div><div>Thus a C program m=
ust run exactly the same in C++ as it would in C. Making the cmath function=
s go constexpr in C++ breaks that, badly.</div><div><br></div><div>Niall</d=
iv><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&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/79697376-5ccd-470a-b197-ab717ae1d64a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/79697376-5ccd-470a-b197-ab717ae1d64a=
%40isocpp.org</a>.<br />

------=_Part_3658_1234269762.1507417314853--

------=_Part_3657_537714681.1507417314853--

.

------=_Part_3838_884389866.1507448362727
Content-Type: multipart/alternative;
 boundary="----=_Part_3839_636047451.1507448362727"

------=_Part_3839_636047451.1507448362727
Content-Type: text/plain; charset="UTF-8"

Just came across this thread. Have not yet had time to digest the various
points made, but wanted to draw attention to

http://open-std.org/JTC1/SC22/WG21/docs/papers/2017/p0533r0.pdf

Please note that the second draft of this paper is currently being
completed and will hopefully be submitted soon. The main change is a
discussion of rounding mode.

On Friday, 6 October 2017 11:45:16 UTC+1, David Brown wrote:
>
> In a recent test I was doing about using constexpr for generating
> compile-time tables, I discovered that expressions like this:
>
>         constexpr auto pi = 4 * std::atan(1);
>
> are accepted by gcc, but not by clang.  It seems that the standards
> don't require functions like std::atan, std::sin, etc., to be constexpr.
>  In the context of embedded systems, being able to make compile-time
> tables of things like sin functions can be an extremely useful feature.
>
> Is there any reason why this could not be supported in the C++ standards?
>
>
>

--
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/9b37c7f2-0c90-4fe4-a0c9-230b7c99af06%40isocpp.org.

------=_Part_3839_636047451.1507448362727
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Just came across this thread. Have not yet had time t=
o digest the various points made, but wanted to draw attention to<br></div>=
<div><br></div><div>http://open-std.org/JTC1/SC22/WG21/docs/papers/2017/p05=
33r0.pdf</div><div><br></div><div>Please note that the second draft of this=
 paper is currently being completed and will hopefully be submitted soon. T=
he main change is a discussion of rounding mode.<br><br>On Friday, 6 Octobe=
r 2017 11:45:16 UTC+1, David Brown  wrote:<blockquote class=3D"gmail_quote"=
 style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-=
left: 1ex;">In a recent test I was doing about using constexpr for generati=
ng
<br>compile-time tables, I discovered that expressions like this:
<br>
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0constexpr auto pi =3D 4=
 * std::atan(1);
<br>
<br>are accepted by gcc, but not by clang. =C2=A0It seems that the standard=
s
<br>don&#39;t require functions like std::atan, std::sin, etc., to be const=
expr.
<br>=C2=A0In the context of embedded systems, being able to make compile-ti=
me
<br>tables of things like sin functions can be an extremely useful feature.
<br>
<br>Is there any reason why this could not be supported in the C++ standard=
s?
<br>
<br>
<br></blockquote></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/9b37c7f2-0c90-4fe4-a0c9-230b7c99af06%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9b37c7f2-0c90-4fe4-a0c9-230b7c99af06=
%40isocpp.org</a>.<br />

------=_Part_3839_636047451.1507448362727--

------=_Part_3838_884389866.1507448362727--

.

On 08/10/17 01:01, Niall Douglas wrote:
> On Saturday, October 7, 2017 at 1:24:46 AM UTC+1, David Brown wrote:
>=20
>=20
>     On 06/10/17 17:48, Niall Douglas wrote:
>      >
>      > =C2=A0 =C2=A0 Is there any reason why this could not be supported =
in the C++
>      > =C2=A0 =C2=A0 standards?
>      >
>      > Breaks compatibility with C I would imagine.
>      >
>=20
>     That would be a reasonable (but not great) justification - though I
>     don't see how it would. =C2=A0Perhaps errno support would be the prob=
lem?
>=20
>=20
> It's not even that.
>=20
> A very common use case for C++ is to compile straight-C programs for the=
=20
> improved optimisation.
>=20
> Thus a C program must run exactly the same in C++ as it would in C.=20
> Making the cmath functions go constexpr in C++ breaks that, badly.
>=20

/What/ would break?  In all the code I have written, there is nothing=20
about "sin" or other <math.h> functions that cannot be pre-calculated.=20
"sin(x)" gives the same result for compile-time constant x whether it is=20
done at run time or at compile time.  You sound so convinced that it=20
would "break badly" to do this calculation at run time (though compilers=20
certainly /do/ handle this at compile time - gcc has no problem with=20
using sin() in constexpr functions and initialisation).  What am I missing?

--=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/d170ed43-361a-c5df-ff46-157240760a97%40westcontr=
ol.com.

.

------=_Part_5162_1218010375.1507508851912
Content-Type: multipart/alternative;
 boundary="----=_Part_5163_419538994.1507508851912"

------=_Part_5163_419538994.1507508851912
Content-Type: text/plain; charset="UTF-8"


>
> > It's not even that.
> >
> > A very common use case for C++ is to compile straight-C programs for the
> > improved optimisation.
> >
> > Thus a C program must run exactly the same in C++ as it would in C.
> > Making the cmath functions go constexpr in C++ breaks that, badly.
> >
>
> /What/ would break?  In all the code I have written, there is nothing
> about "sin" or other <math.h> functions that cannot be pre-calculated.


In all the code that *you* have written it may have appeared to have been
safe.

Standards committees decide on the basis of code they will never and can
never see. Retrospectively changing the behaviour of a language or library
feature, apart from fixing defects, very rarely occurs.


>
> "sin(x)" gives the same result for compile-time constant x whether it is
> done at run time or at compile time.  You sound so convinced that it
> would "break badly" to do this calculation at run time (though compilers
> certainly /do/ handle this at compile time - gcc has no problem with
> using sin() in constexpr functions and initialisation).  What am I
> missing?
>
> You also appear to be conflating constant folding during optimisation and
constant expressions evaluation at compile time.

They are not the same. GCC may mark the cmath functions as constexpr as
part of its choice of quality of implementation i.e. as an extension. But
it's not standardisable unless C adds the constexpr facility from C++, and
then implements a breaking change to the spec for the math.h functions.
Which would be very hard to imagine happening.

Nobody is disputing that we need new math functions which more closely
match current hardware. And people are working on that, both in C++ and in
C. But these things take a few years. Indeed until just very recently a
major CPU architecture didn't implement FP NaNs according to spec. That put
a kibosh on any reasonable attempt to standardise "fast-math" until it was
fixed, which it is now in their most recent architecture.

I don't doubt that at some future point, SIMD and fast-math FP will get
standardised both in C and C++. It'll be a different API to cmath because
it's incompatible. But with that you'll get what you want, constexpr
execution. Until then you'll need to rely on compiler extensions or use
third party libraries which implement FP in constexpr.

Niall

--
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/248cdacc-85e4-4e41-aa8b-afe76e9b81c0%40isocpp.org.

------=_Part_5163_419538994.1507508851912
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">&gt; It&#39;s=
 not even that.
<br>&gt;=20
<br>&gt; A very common use case for C++ is to compile straight-C programs f=
or the=20
<br>&gt; improved optimisation.
<br>&gt;=20
<br>&gt; Thus a C program must run exactly the same in C++ as it would in C=
..=20
<br>&gt; Making the cmath functions go constexpr in C++ breaks that, badly.
<br>&gt;=20
<br>
<br>/What/ would break? =C2=A0In all the code I have written, there is noth=
ing=20
<br>about &quot;sin&quot; or other &lt;math.h&gt; functions that cannot be =
pre-calculated. </blockquote><div><br></div><div>In all the code that <i>yo=
u</i>=C2=A0have written it may have appeared to have been safe.</div><div><=
br></div><div>Standards committees decide on the basis of code they will ne=
ver and can never see. Retrospectively changing the behaviour of a language=
 or library feature, apart from fixing defects, very rarely occurs.</div><d=
iv>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>&quot;sin(x)&quot; gives the same result for compile-time constant x wh=
ether it is=20
<br>done at run time or at compile time. =C2=A0You sound so convinced that =
it=20
<br>would &quot;break badly&quot; to do this calculation at run time (thoug=
h compilers=20
<br>certainly /do/ handle this at compile time - gcc has no problem with=20
<br>using sin() in constexpr functions and initialisation). =C2=A0What am I=
 missing?
<br>
<br></blockquote><div>You also appear to be conflating constant folding dur=
ing optimisation and constant expressions evaluation at compile time.</div>=
<div><br></div><div>They are not the same. GCC may mark the cmath functions=
 as constexpr as part of its choice of quality of implementation i.e. as an=
 extension. But it&#39;s not standardisable unless C adds the constexpr fac=
ility from C++, and then implements a breaking change to the spec for the m=
ath.h functions. Which would be very hard to imagine happening.</div><div><=
br></div><div>Nobody is disputing that we need new math functions which mor=
e closely match current hardware. And people are working on that, both in C=
++ and in C. But these things take a few years. Indeed until just very rece=
ntly a major CPU architecture didn&#39;t implement FP NaNs according to spe=
c. That put a kibosh on any reasonable attempt to standardise &quot;fast-ma=
th&quot; until it was fixed, which it is now in their most recent architect=
ure.</div><div><br></div><div>I don&#39;t doubt that at some future point, =
SIMD and fast-math FP will get standardised both in C and C++. It&#39;ll be=
 a different API to cmath because it&#39;s incompatible. But with that you&=
#39;ll get what you want, constexpr execution. Until then you&#39;ll need t=
o rely on compiler extensions or use third party libraries which implement =
FP in constexpr.</div><div><br></div><div>Niall</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/248cdacc-85e4-4e41-aa8b-afe76e9b81c0%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/248cdacc-85e4-4e41-aa8b-afe76e9b81c0=
%40isocpp.org</a>.<br />

------=_Part_5163_419538994.1507508851912--

------=_Part_5162_1218010375.1507508851912--

.

On 08/10/17 09:39, oliver.rosten@googlemail.com wrote:
> Just came across this thread. Have not yet had time to digest the=20
> various points made, but wanted to draw attention to
>=20
> http://open-std.org/JTC1/SC22/WG21/docs/papers/2017/p0533r0.pdf
>=20
> Please note that the second draft of this paper is currently being=20
> completed and will hopefully be submitted soon. The main change is a=20
> discussion of rounding mode.

Thanks for that link.

Unfortunately, to me, that proposal mostly misses the point.  It is=20
great that functions such as "trunc" and "fmod" can me made constexpr.=20
It is /long/ overdue that functions like "abs" and "fmin" are made=20
constexpr - these can be implemented with a one-line template function=20
which every mainstream compiler will optimise smoothly.

However, the proposal does not go far enough to suit me.

The restriction on "the function being closed on the set of extended=20
rational numbers" is not necessary, and not useful.  Clearly it is not=20
necessary - gcc manages happily to have functions like "sin" defined as=20
constexpr.  Clearly it is not useful, as it excludes important and=20
popular functions.  It is not even sensibly defined - there is no such=20
thing as a "set of extended rational numbers" and no definition of it in=20
the proposal.  Either you consider floating point as an approximation=20
for real numbers (in which case these functions /are/ closed, at least=20
for a useful subdomain), or you consider them as functions on the set of=20
numbers representable as computer floating point numbers of various=20
types, in which case the functions are /still/ closed (on a useful=20
subdomain).  Meanwhile, functions like "division" are constexpr without=20
being closed on the field (you can't divide by 0), "abs" is to be=20
constexpr without being well-defined over the whole domain (you can't=20
take the abs value of the lowest possible integer on most systems).=20
Basic arithmetic can overflow.  The whole thing is inconsistent, and too=20
limited to be useful in many cases where you really want compile-time=20
generation of results (such as for trig and power operations).  All it=20
gives you is constexpr for functions that are almost never used (who=20
uses "islessequal(x, y)" rather than "x < y" ?) except in very niche=20
cases, and functions that are trivial to implement as constexpr template=20
functions.


In my opinion, the dependency of floating point operations on a diffuse=20
"floating point environment" is something that should have been=20
deprecated eons ago.  The function "sin" should return an approximation=20
to the sine of its argument.  It is never going to be mathematically=20
correct (except for occasional values, like 0).  The IEEE standards give=20
reasonable criteria for accuracy, supported by lots of hardware and=20
software implementations.  But functions like this should be state-free=20
- they are /functions/, in the mathematical sense.  They should not=20
depend on the state.  Sure, there will be /some/ people who want to=20
specify rounding mode FE_DOWNWARD at some points in their code, and=20
FE_UPWARD at other points.  IMHO, they should be using types=20
double_round_downward and double_round_upward, not type double with a=20
set state.  That would give them better control of exactly what they are=20
doing - while the rest of us, almost every user of floating point maths,=20
can use double in FE_DONT_KNOW_AND_DONT_CARE_AT_ALL rounding mode.


Compatibility with C, and compatibility with existing programs, is of=20
course paramount.  I would propose a better compromise would be to=20
introduce a nested namespace std::ce:: for constexpr compatible=20
functions like std::ce::sin, std::ce::pow, std::ce::abs.  Rounding modes=20
would be fixed - a compiler would either support a single rounding mode,=20
or make it configurable with compiler switches, pragmas, etc.  Ideally,=20
these functions would give compile-time errors on failure (like=20
std::ce::sqrt(-1) ), but I would be happy enough with a "garbage in,=20
garbage out" solution.  And when used outside constexpr context, the=20
nice C++ solution would be exceptions - again, I would be happy with=20
undefined behaviour, and I think adoption would be easier if this is=20
implementation defined.  This namespace would include a variety of=20
useful functions from <cmath>, but would certainly avoid the unnecessary=20
name variants that are left-overs from C before <tgmath.h>.


>=20
> On Friday, 6 October 2017 11:45:16 UTC+1, David Brown wrote:
>=20
>     In a recent test I was doing about using constexpr for generating
>     compile-time tables, I discovered that expressions like this:
>=20
>      =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0constexpr auto pi =
=3D 4 * std::atan(1);
>=20
>     are accepted by gcc, but not by clang. =C2=A0It seems that the standa=
rds
>     don't require functions like std::atan, std::sin, etc., to be
>     constexpr.
>      =C2=A0In the context of embedded systems, being able to make compile=
-time
>     tables of things like sin functions can be an extremely useful featur=
e.
>=20
>     Is there any reason why this could not be supported in the C++
>     standards?
>=20
>=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/406fbd9f-2448-9fda-022b-e4ca9fe93a13%40westcontr=
ol.com.

.

On 09/10/17 02:27, Niall Douglas wrote:
>      > It's not even that.
>      >
>      > A very common use case for C++ is to compile straight-C programs
>     for the
>      > improved optimisation.
>      >
>      > Thus a C program must run exactly the same in C++ as it would in C=
..
>      > Making the cmath functions go constexpr in C++ breaks that, badly.
>      >
>=20
>     /What/ would break? =C2=A0In all the code I have written, there is no=
thing
>     about "sin" or other <math.h> functions that cannot be pre-calculated=
..=20
>=20
>=20
> In all the code that /you/=C2=A0have written it may have appeared to have=
=20
> been safe.

Agreed.  That is why I am asking you what you see would break so badly -=20
precisely because I /don't/ see it.

>=20
> Standards committees decide on the basis of code they will never and can=
=20
> never see. Retrospectively changing the behaviour of a language or=20
> library feature, apart from fixing defects, very rarely occurs.
>=20
>=20
>     "sin(x)" gives the same result for compile-time constant x whether
>     it is
>     done at run time or at compile time. =C2=A0You sound so convinced tha=
t it
>     would "break badly" to do this calculation at run time (though
>     compilers
>     certainly /do/ handle this at compile time - gcc has no problem with
>     using sin() in constexpr functions and initialisation). =C2=A0What am=
 I
>     missing?
>=20
> You also appear to be conflating constant folding during optimisation=20
> and constant expressions evaluation at compile time.

No, I don't think I am.  I expect compilers to be able to do=20
optimisations above and beyond what they accept as valid syntax.  A=20
compiler can happily pre-calculate "sin(0.5)" for optimisation purposes=20
even though it rejects its use in a constexpr.

>=20
> They are not the same. GCC may mark the cmath functions as constexpr as=
=20
> part of its choice of quality of implementation i.e. as an extension.=20
> But it's not standardisable unless C adds the constexpr facility from=20
> C++, and then implements a breaking change to the spec for the math.h=20
> functions. Which would be very hard to imagine happening.

I cannot see that as a requirement.  There is nothing in the C++=20
standards to require <cmath> to match <math.h> that closely.  In fact,=20
the standard explicitly requires that <cmath> makes /additions/ to=20
<math.h>, such as overloads for a number of functions as an alternative=20
to asking for different function versions by name like C.  I fail to see=20
why an implementation might happily retain "double sin(double x);" in=20
<math.h> and have "constexpr double sin(double x);" in <cmath>.

>=20
> Nobody is disputing that we need new math functions which more closely=20
> match current hardware. And people are working on that, both in C++ and=
=20
> in C. But these things take a few years. Indeed until just very recently=
=20
> a major CPU architecture didn't implement FP NaNs according to spec.=20
> That put a kibosh on any reasonable attempt to standardise "fast-math"=20
> until it was fixed, which it is now in their most recent architecture.

"fast-math", at least the term I know (the gcc optimisation),=20
specifically excludes any worry about NaNs.  There are quite a few=20
embedded processors with limited floating point hardware that does not=20
handle that sort of thing properly (in the IEEE sense).  These hardware=20
units either give some sort of default result, give garbage results, or=20
through a hardware exception.  That is /fine/ for a great deal of=20
software - I expect that very little code has any interest in NaNs and=20
other complications in floating point.  I feel frustration that the=20
needs of the many - who just want to divide 1.0 by 3.0 and get 3.3333333=20
- are given such low priority because of the tiny few who want to argue=20
if it should be 3.3333333333333333333333 or 3.3333333333333333333334.

>=20
> I don't doubt that at some future point, SIMD and fast-math FP will get=
=20
> standardised both in C and C++. It'll be a different API to cmath=20
> because it's incompatible. But with that you'll get what you want,=20
> constexpr execution. Until then you'll need to rely on compiler=20
> extensions or use third party libraries which implement FP in constexpr.
>=20

I started this thread after being in a discussion on Usenet about=20
pre-calculating sin tables in C++, especially after C++14 allowed loops=20
and such in constexpr functions.  A search on google shows a way to=20
handle this in standard C++ - using recursive templates to define your=20
own sine function from Taylor series.  That is /ridiculous/.  There is=20
no good excuse for that.  I was able to make a vastly simpler solution,=20
using std::sin, but limited to gcc where std::sin is constexpr.

> Niall

--=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/d7481e86-cda3-8407-7666-8212886695f0%40westcontr=
ol.com.

.

--001a11448c32656471055b1c8115
Content-Type: text/plain; charset="UTF-8"

Hi David,

Thanks for the feedback.

I think that our endgame is the same: we both want to see pretty much every
function in cmath declared, one way or another, constexpr. Indeed, our
latest working draft includes a section 'Future Directions' in which we
state our desire to extend what we've done to almost all of cmath.

However, we were advised - and in hindsight this advice has proven
excellent - not to be this ambitious yet. Focusing just on the functions
declared constexpr in our paper revealed several subtleties, not all of
which we appreciated when the first draft was submitted.

On 9 October 2017 at 10:58, David Brown <david@westcontrol.com> wrote:

>
> On 08/10/17 09:39, oliver.rosten@googlemail.com wrote:
>
>> Just came across this thread. Have not yet had time to digest the various
>> points made, but wanted to draw attention to
>>
>> http://open-std.org/JTC1/SC22/WG21/docs/papers/2017/p0533r0.pdf
>>
>> Please note that the second draft of this paper is currently being
>> completed and will hopefully be submitted soon. The main change is a
>> discussion of rounding mode.
>>
>
> Thanks for that link.
>
> Unfortunately, to me, that proposal mostly misses the point.  It is great
> that functions such as "trunc" and "fmod" can me made constexpr. It is
> /long/ overdue that functions like "abs" and "fmin" are made constexpr -
> these can be implemented with a one-line template function which every
> mainstream compiler will optimise smoothly.
>
> However, the proposal does not go far enough to suit me.
>
> The restriction on "the function being closed on the set of extended
> rational numbers" is not necessary, and not useful.  Clearly it is not
> necessary - gcc manages happily to have functions like "sin" defined as
> constexpr.  Clearly it is not useful, as it excludes important and popular
> functions.  It is not even sensibly defined - there is no such thing as a
> "set of extended rational numbers" and no definition of it in the
> proposal.  Either you consider floating point as an approximation for real
> numbers (in which case these functions /are/ closed, at least for a useful
> subdomain), or you consider them as functions on the set of numbers
> representable as computer floating point numbers of various types, in which
> case the functions are /still/ closed (on a useful subdomain).  Meanwhile,
> functions like "division" are constexpr without being closed on the field
> (you can't divide by 0), "abs" is to be constexpr without being
> well-defined over the whole domain (you can't take the abs value of the
> lowest possible integer on most systems). Basic arithmetic can overflow.
> The whole thing is inconsistent, and too limited to be useful in many cases
> where you really want compile-time generation of results (such as for trig
> and power operations).  All it gives you is constexpr for functions that
> are almost never used (who uses "islessequal(x, y)" rather than "x < y" ?)
> except in very niche cases, and functions that are trivial to implement as
> constexpr template functions.
>
>
> In my opinion, the dependency of floating point operations on a diffuse
> "floating point environment" is something that should have been deprecated
> eons ago.  The function "sin" should return an approximation to the sine of
> its argument.  It is never going to be mathematically correct (except for
> occasional values, like 0).  The IEEE standards give reasonable criteria
> for accuracy, supported by lots of hardware and software implementations.
> But functions like this should be state-free - they are /functions/, in the
> mathematical sense.  They should not depend on the state.  Sure, there will
> be /some/ people who want to specify rounding mode FE_DOWNWARD at some
> points in their code, and FE_UPWARD at other points.  IMHO, they should be
> using types double_round_downward and double_round_upward, not type double
> with a set state.  That would give them better control of exactly what they
> are doing - while the rest of us, almost every user of floating point
> maths, can use double in FE_DONT_KNOW_AND_DONT_CARE_AT_ALL rounding mode.
>
>
> Compatibility with C, and compatibility with existing programs, is of
> course paramount.  I would propose a better compromise would be to
> introduce a nested namespace std::ce:: for constexpr compatible functions
> like std::ce::sin, std::ce::pow, std::ce::abs.  Rounding modes would be
> fixed - a compiler would either support a single rounding mode, or make it
> configurable with compiler switches, pragmas, etc.  Ideally, these
> functions would give compile-time errors on failure (like std::ce::sqrt(-1)
> ), but I would be happy enough with a "garbage in, garbage out" solution.
> And when used outside constexpr context, the nice C++ solution would be
> exceptions - again, I would be happy with undefined behaviour, and I think
> adoption would be easier if this is implementation defined.  This namespace
> would include a variety of useful functions from <cmath>, but would
> certainly avoid the unnecessary name variants that are left-overs from C
> before <tgmath.h>.
>
>
>
>> On Friday, 6 October 2017 11:45:16 UTC+1, David Brown wrote:
>>
>>     In a recent test I was doing about using constexpr for generating
>>     compile-time tables, I discovered that expressions like this:
>>
>>              constexpr auto pi = 4 * std::atan(1);
>>
>>     are accepted by gcc, but not by clang.  It seems that the standards
>>     don't require functions like std::atan, std::sin, etc., to be
>>     constexpr.
>>       In the context of embedded systems, being able to make compile-time
>>     tables of things like sin functions can be an extremely useful
>> feature.
>>
>>     Is there any reason why this could not be supported in the C++
>>     standards?
>>
>>
>>

--
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/CAEu-ZVQcXbh06vevLa0dZnbzzwNJ1KWP3cR9cwZQEWo8_95ikQ%40mail.gmail.com.

--001a11448c32656471055b1c8115
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi David,<div><br></div><div>Thanks for the feedback.</div=
><div><br></div><div>I think that our endgame is the same: we both want to =
see pretty much every function in cmath declared, one way or another, const=
expr. Indeed, our latest working draft includes a section &#39;Future Direc=
tions&#39; in which we state our desire to extend what we&#39;ve done to al=
most all of cmath.</div><div><br></div><div>However, we were advised - and =
in hindsight this advice has proven excellent - not to be this ambitious ye=
t. Focusing just on the functions declared constexpr in our paper revealed =
several subtleties, not all of which we appreciated when the first draft wa=
s submitted.=C2=A0</div></div><div class=3D"gmail_extra"><br><div class=3D"=
gmail_quote">On 9 October 2017 at 10:58, David Brown <span dir=3D"ltr">&lt;=
<a href=3D"mailto:david@westcontrol.com" target=3D"_blank">david@westcontro=
l.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
On 08/10/17 09:39, <a href=3D"mailto:oliver.rosten@googlemail.com" target=
=3D"_blank">oliver.rosten@googlemail.com</a> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Just came across this thread. Have not yet had time to digest the various p=
oints made, but wanted to draw attention to<br>
<br>
<a href=3D"http://open-std.org/JTC1/SC22/WG21/docs/papers/2017/p0533r0.pdf"=
 rel=3D"noreferrer" target=3D"_blank">http://open-std.org/JTC1/SC22/<wbr>WG=
21/docs/papers/2017/p0533r0.<wbr>pdf</a><br>
<br>
Please note that the second draft of this paper is currently being complete=
d and will hopefully be submitted soon. The main change is a discussion of =
rounding mode.<br>
</blockquote>
<br>
Thanks for that link.<br>
<br>
Unfortunately, to me, that proposal mostly misses the point.=C2=A0 It is gr=
eat that functions such as &quot;trunc&quot; and &quot;fmod&quot; can me ma=
de constexpr. It is /long/ overdue that functions like &quot;abs&quot; and =
&quot;fmin&quot; are made constexpr - these can be implemented with a one-l=
ine template function which every mainstream compiler will optimise smoothl=
y.<br>
<br>
However, the proposal does not go far enough to suit me.<br>
<br>
The restriction on &quot;the function being closed on the set of extended r=
ational numbers&quot; is not necessary, and not useful.=C2=A0 Clearly it is=
 not necessary - gcc manages happily to have functions like &quot;sin&quot;=
 defined as constexpr.=C2=A0 Clearly it is not useful, as it excludes impor=
tant and popular functions.=C2=A0 It is not even sensibly defined - there i=
s no such thing as a &quot;set of extended rational numbers&quot; and no de=
finition of it in the proposal.=C2=A0 Either you consider floating point as=
 an approximation for real numbers (in which case these functions /are/ clo=
sed, at least for a useful subdomain), or you consider them as functions on=
 the set of numbers representable as computer floating point numbers of var=
ious types, in which case the functions are /still/ closed (on a useful sub=
domain).=C2=A0 Meanwhile, functions like &quot;division&quot; are constexpr=
 without being closed on the field (you can&#39;t divide by 0), &quot;abs&q=
uot; is to be constexpr without being well-defined over the whole domain (y=
ou can&#39;t take the abs value of the lowest possible integer on most syst=
ems). Basic arithmetic can overflow.=C2=A0 The whole thing is inconsistent,=
 and too limited to be useful in many cases where you really want compile-t=
ime generation of results (such as for trig and power operations).=C2=A0 Al=
l it gives you is constexpr for functions that are almost never used (who u=
ses &quot;islessequal(x, y)&quot; rather than &quot;x &lt; y&quot; ?) excep=
t in very niche cases, and functions that are trivial to implement as const=
expr template functions.<br>
<br>
<br>
In my opinion, the dependency of floating point operations on a diffuse &qu=
ot;floating point environment&quot; is something that should have been depr=
ecated eons ago.=C2=A0 The function &quot;sin&quot; should return an approx=
imation to the sine of its argument.=C2=A0 It is never going to be mathemat=
ically correct (except for occasional values, like 0).=C2=A0 The IEEE stand=
ards give reasonable criteria for accuracy, supported by lots of hardware a=
nd software implementations.=C2=A0 But functions like this should be state-=
free - they are /functions/, in the mathematical sense.=C2=A0 They should n=
ot depend on the state.=C2=A0 Sure, there will be /some/ people who want to=
 specify rounding mode FE_DOWNWARD at some points in their code, and FE_UPW=
ARD at other points.=C2=A0 IMHO, they should be using types double_round_do=
wnward and double_round_upward, not type double with a set state.=C2=A0 Tha=
t would give them better control of exactly what they are doing - while the=
 rest of us, almost every user of floating point maths, can use double in F=
E_DONT_KNOW_AND_DONT_CARE_AT_<wbr>ALL rounding mode.<br>
<br>
<br>
Compatibility with C, and compatibility with existing programs, is of cours=
e paramount.=C2=A0 I would propose a better compromise would be to introduc=
e a nested namespace std::ce:: for constexpr compatible functions like std:=
:ce::sin, std::ce::pow, std::ce::abs.=C2=A0 Rounding modes would be fixed -=
 a compiler would either support a single rounding mode, or make it configu=
rable with compiler switches, pragmas, etc.=C2=A0 Ideally, these functions =
would give compile-time errors on failure (like std::ce::sqrt(-1) ), but I =
would be happy enough with a &quot;garbage in, garbage out&quot; solution.=
=C2=A0 And when used outside constexpr context, the nice C++ solution would=
 be exceptions - again, I would be happy with undefined behaviour, and I th=
ink adoption would be easier if this is implementation defined.=C2=A0 This =
namespace would include a variety of useful functions from &lt;cmath&gt;, b=
ut would certainly avoid the unnecessary name variants that are left-overs =
from C before &lt;tgmath.h&gt;.<br>
<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<br>
On Friday, 6 October 2017 11:45:16 UTC+1, David Brown wrote:<br>
<br>
=C2=A0 =C2=A0 In a recent test I was doing about using constexpr for genera=
ting<br>
=C2=A0 =C2=A0 compile-time tables, I discovered that expressions like this:=
<br>
<br>
=C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0constex=
pr auto pi =3D 4 * std::atan(1);<br>
<br>
=C2=A0 =C2=A0 are accepted by gcc, but not by clang.=C2=A0 It seems that th=
e standards<br>
=C2=A0 =C2=A0 don&#39;t require functions like std::atan, std::sin, etc., t=
o be<br>
=C2=A0 =C2=A0 constexpr.<br>
=C2=A0 =C2=A0 =C2=A0=C2=A0In the context of embedded systems, being able to=
 make compile-time<br>
=C2=A0 =C2=A0 tables of things like sin functions can be an extremely usefu=
l feature.<span class=3D""><br>
<br>
=C2=A0 =C2=A0 Is there any reason why this could not be supported in the C+=
+<br>
=C2=A0 =C2=A0 standards?<br>
<br>
<br>
</span></blockquote>
</blockquote></div><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/CAEu-ZVQcXbh06vevLa0dZnbzzwNJ1KWP3cR9=
cwZQEWo8_95ikQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEu-ZVQcXbh06vev=
La0dZnbzzwNJ1KWP3cR9cwZQEWo8_95ikQ%40mail.gmail.com</a>.<br />

--001a11448c32656471055b1c8115--

.

On 09/10/17 14:41, Oliver Rosten wrote:
> Hi David,
>=20
> Thanks for the feedback.
>=20
> I think that our endgame is the same: we both want to see pretty much=20
> every function in cmath declared, one way or another, constexpr. Indeed,=
=20
> our latest working draft includes a section 'Future Directions' in which=
=20
> we state our desire to extend what we've done to almost all of cmath.
>=20
> However, we were advised - and in hindsight this advice has proven=20
> excellent - not to be this ambitious yet. Focusing just on the functions=
=20
> declared constexpr in our paper revealed several subtleties, not all of=
=20
> which we appreciated when the first draft was submitted.

That sounds like the best I can hope for here.  I appreciate that things=20
that appear simple and obvious from the point of view of a user like me=20
can be far more complicated in the big picture of the standards - and=20
that something that might be easy for one implementation to support=20
could be far more difficult for other implementations.  I am glad you=20
understand what I am looking for here, and I am very glad that you are=20
working towards it - even if progress is slower than a na=C3=AFve user like=
=20
myself would like.

One thing that might be useful for your proposal paper is to look at the=20
kinds of use-cases for making these functions constexpr.  For many uses,=20
it is not actually that important to have the functions constexpr as=20
long as compilers can optimise them and pre-compute the results.  The=20
real gains (for me, anyway) are for pre-computed tables.  I work mostly=20
with small embedded systems - on these targets, something like "sin" is=20
going to be very slow to calculate, and require libraries taking a=20
significant amount of program space.  When you need sine functions, as=20
you regularly do (such as for motor control), you use lookup tables and=20
interpolation of various sorts.  Being able to calculate these=20
efficiently within C++ at compile, instead of using separate table=20
generator scripts, cut-and-paste from spreadsheets, and other such=20
methods - it's just /lovely/ to be able to write it all in the C++ code.=20
  Here is a simple example I wrote earlier for a Usenet posting.  It=20
works fine in gcc (which is the compiler I use most), but it would be=20
great to see it supported by the standard.

mvh.,

David


#include <stdint.h>
#include <cmath>

constexpr double const_sine(double x) {
     return std::sin(x);
}

const auto pi =3D 3.14159265358979323846264338327;
const auto pi2 =3D 2 * pi;

template<class T, int N> struct array {
     T elems[N];

     constexpr T& operator[](size_t i) {
         return elems[i];
     }
     constexpr const T& operator[](size_t i) const {
         return elems[i];
     }
};

const auto size =3D 128;
using Table =3D array<int16_t, size>;

constexpr Table makeTable() {
     Table t{};
     for (auto i =3D 0; i < size; i++) {
         const auto angle =3D (i * pi2 / size);
         const auto s =3D const_sine(angle);
         t[i] =3D 32767 * s;
     }
     return t;
}

extern const Table sine_table =3D makeTable();

--=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/2693e826-aa69-b48a-6bf4-d46e138a38ee%40westcontr=
ol.com.

.

--001a1147bbf4d0da7f055b1f20ee
Content-Type: text/plain; charset="UTF-8"

On Mon, Oct 9, 2017 at 8:56 AM, David Brown <david@westcontrol.com> wrote:
>
> const auto pi = 3.14159265358979323846264338327;


If you are targeting systems that use IEEE-754 floating point, a decimal
with no
more than 17 significant digits is sufficient to specify every possible
double value.
For this value, a 16-digit number suffices.  So,

    const auto pi = 3.141592653589793;

Specifying more digits does not change the value stored in pi, and sends a
poor
message to readers of the code, implying that specifying so many digits is
good
and useful, when it is not.

--
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/CAHSYqdbC0WT9bNN91hfsHpkWWfc8AYYANqSLDxY3rpHNpUPm5Q%40mail.gmail.com.

--001a1147bbf4d0da7f055b1f20ee
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Oct 9, 2017 at 8:56 AM, David Brown <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:david@westcontrol.com" target=3D"_blank">david@westcontrol.com</a>&gt;=
</span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
const auto pi =3D 3.1415926535897932384626433832<wbr>7;</blockquote><div><b=
r>If you are targeting systems that use IEEE-754 floating point, a decimal =
with no<br>more than 17 significant digits is sufficient to specify every p=
ossible <font face=3D"monospace, monospace">double</font> value.<br>For thi=
s value, a 16-digit number suffices.=C2=A0 So,<br><br><font face=3D"monospa=
ce, monospace">=C2=A0 =C2=A0 const auto pi =3D 3.141592653589793;</font><br=
><br>Specifying more digits does not change the value stored in <font face=
=3D"monospace, monospace">pi</font>, and sends a poor<br>message to readers=
 of the code, implying that specifying so many digits is good<br>and useful=
, when it is not.</div></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/CAHSYqdbC0WT9bNN91hfsHpkWWfc8AYYANqSL=
DxY3rpHNpUPm5Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdbC0WT9bNN9=
1hfsHpkWWfc8AYYANqSLDxY3rpHNpUPm5Q%40mail.gmail.com</a>.<br />

--001a1147bbf4d0da7f055b1f20ee--

.

------=_Part_6994_1301681308.1507600453183
Content-Type: multipart/alternative;
 boundary="----=_Part_6995_1600751633.1507600453184"

------=_Part_6995_1600751633.1507600453184
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



=E5=9C=A8 2017=E5=B9=B410=E6=9C=889=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=80 UTC=
+8=E4=B8=8B=E5=8D=888:57:01=EF=BC=8CDavid Brown=E5=86=99=E9=81=93=EF=BC=9A
>
>
> On 09/10/17 14:41, Oliver Rosten wrote:=20
> > Hi David,=20
> >=20
> > Thanks for the feedback.=20
> >=20
> > I think that our endgame is the same: we both want to see pretty much=
=20
> > every function in cmath declared, one way or another, constexpr. Indeed=
,=20
> > our latest working draft includes a section 'Future Directions' in whic=
h=20
> > we state our desire to extend what we've done to almost all of cmath.=
=20
> >=20
> > However, we were advised - and in hindsight this advice has proven=20
> > excellent - not to be this ambitious yet. Focusing just on the function=
s=20
> > declared constexpr in our paper revealed several subtleties, not all of=
=20
> > which we appreciated when the first draft was submitted.=20
>
> That sounds like the best I can hope for here.  I appreciate that things=
=20
> that appear simple and obvious from the point of view of a user like me=
=20
> can be far more complicated in the big picture of the standards - and=20
> that something that might be easy for one implementation to support=20
> could be far more difficult for other implementations.  I am glad you=20
> understand what I am looking for here, and I am very glad that you are=20
> working towards it - even if progress is slower than a na=C3=AFve user li=
ke=20
> myself would like.=20
>
> One thing that might be useful for your proposal paper is to look at the=
=20
> kinds of use-cases for making these functions constexpr.  For many uses,=
=20
> it is not actually that important to have the functions constexpr as=20
> long as compilers can optimise them and pre-compute the results.  The=20
> real gains (for me, anyway) are for pre-computed tables.  I work mostly=
=20
> with small embedded systems - on these targets, something like "sin" is=
=20
> going to be very slow to calculate, and require libraries taking a=20
> significant amount of program space.  When you need sine functions, as=20
> you regularly do (such as for motor control), you use lookup tables and=
=20
> interpolation of various sorts.  Being able to calculate these=20
> efficiently within C++ at compile, instead of using separate table=20
> generator scripts, cut-and-paste from spreadsheets, and other such=20
> methods - it's just /lovely/ to be able to write it all in the C++ code.=
=20
>   Here is a simple example I wrote earlier for a Usenet posting.  It=20
> works fine in gcc (which is the compiler I use most), but it would be=20
> great to see it supported by the standard.=20
>
> mvh.,=20
>
> David=20
>
>
> #include <stdint.h>=20
> #include <cmath>=20
>
> constexpr double const_sine(double x) {=20
>      return std::sin(x);=20
> }=20
>
> const auto pi =3D 3.14159265358979323846264338327;=20
>

Is it rounded?.

IIRC it is 3.141592653589793238462643383279502884197169399...

const auto pi2 =3D 2 * pi;=20
>
> template<class T, int N> struct array {=20
>      T elems[N];=20
>
>      constexpr T& operator[](size_t i) {=20
>          return elems[i];=20
>      }=20
>      constexpr const T& operator[](size_t i) const {=20
>          return elems[i];=20
>      }=20
> };=20
>
> const auto size =3D 128;=20
> using Table =3D array<int16_t, size>;=20
>
> constexpr Table makeTable() {=20
>      Table t{};=20
>      for (auto i =3D 0; i < size; i++) {=20
>          const auto angle =3D (i * pi2 / size);=20
>          const auto s =3D const_sine(angle);=20
>          t[i] =3D 32767 * s;=20
>      }=20
>      return t;=20
> }=20
>
> extern const Table sine_table =3D makeTable();=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/f24eb175-3da2-4d8d-88b5-2265c0c79a77%40isocpp.or=
g.

------=_Part_6995_1600751633.1507600453184
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>=E5=9C=A8 2017=E5=B9=B410=E6=9C=889=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=B8=80 UTC+8=E4=B8=8B=E5=8D=888:57:01=EF=BC=8CDavid Brown=E5=
=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>On 09/10/17 14:41, Oliver Rosten wrote:
<br>&gt; Hi David,
<br>&gt;=20
<br>&gt; Thanks for the feedback.
<br>&gt;=20
<br>&gt; I think that our endgame is the same: we both want to see pretty m=
uch=20
<br>&gt; every function in cmath declared, one way or another, constexpr. I=
ndeed,=20
<br>&gt; our latest working draft includes a section &#39;Future Directions=
&#39; in which=20
<br>&gt; we state our desire to extend what we&#39;ve done to almost all of=
 cmath.
<br>&gt;=20
<br>&gt; However, we were advised - and in hindsight this advice has proven=
=20
<br>&gt; excellent - not to be this ambitious yet. Focusing just on the fun=
ctions=20
<br>&gt; declared constexpr in our paper revealed several subtleties, not a=
ll of=20
<br>&gt; which we appreciated when the first draft was submitted.
<br>
<br>That sounds like the best I can hope for here. =C2=A0I appreciate that =
things=20
<br>that appear simple and obvious from the point of view of a user like me=
=20
<br>can be far more complicated in the big picture of the standards - and=
=20
<br>that something that might be easy for one implementation to support=20
<br>could be far more difficult for other implementations. =C2=A0I am glad =
you=20
<br>understand what I am looking for here, and I am very glad that you are=
=20
<br>working towards it - even if progress is slower than a na=C3=AFve user =
like=20
<br>myself would like.
<br>
<br>One thing that might be useful for your proposal paper is to look at th=
e=20
<br>kinds of use-cases for making these functions constexpr. =C2=A0For many=
 uses,=20
<br>it is not actually that important to have the functions constexpr as=20
<br>long as compilers can optimise them and pre-compute the results. =C2=A0=
The=20
<br>real gains (for me, anyway) are for pre-computed tables. =C2=A0I work m=
ostly=20
<br>with small embedded systems - on these targets, something like &quot;si=
n&quot; is=20
<br>going to be very slow to calculate, and require libraries taking a=20
<br>significant amount of program space. =C2=A0When you need sine functions=
, as=20
<br>you regularly do (such as for motor control), you use lookup tables and=
=20
<br>interpolation of various sorts. =C2=A0Being able to calculate these=20
<br>efficiently within C++ at compile, instead of using separate table=20
<br>generator scripts, cut-and-paste from spreadsheets, and other such=20
<br>methods - it&#39;s just /lovely/ to be able to write it all in the C++ =
code.=20
<br>=C2=A0 Here is a simple example I wrote earlier for a Usenet posting. =
=C2=A0It=20
<br>works fine in gcc (which is the compiler I use most), but it would be=
=20
<br>great to see it supported by the standard.
<br>
<br>mvh.,
<br>
<br>David
<br>
<br>
<br>#include &lt;stdint.h&gt;
<br>#include &lt;cmath&gt;
<br>
<br>constexpr double const_sine(double x) {
<br>=C2=A0 =C2=A0 =C2=A0return std::sin(x);
<br>}
<br>
<br>const auto pi =3D 3.<wbr>14159265358979323846264338327;
<br></blockquote><div><br></div><div>Is it rounded?.<br></div><div><br></di=
v><div>IIRC it is 3.141592653589793238462643383279502884197169399...<br></d=
iv><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">const auto p=
i2 =3D 2 * pi;
<br>
<br>template&lt;class T, int N&gt; struct array {
<br>=C2=A0 =C2=A0 =C2=A0T elems[N];
<br>
<br>=C2=A0 =C2=A0 =C2=A0constexpr T&amp; operator[](size_t i) {
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return elems[i];
<br>=C2=A0 =C2=A0 =C2=A0}
<br>=C2=A0 =C2=A0 =C2=A0constexpr const T&amp; operator[](size_t i) const {
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return elems[i];
<br>=C2=A0 =C2=A0 =C2=A0}
<br>};
<br>
<br>const auto size =3D 128;
<br>using Table =3D array&lt;int16_t, size&gt;;
<br>
<br>constexpr Table makeTable() {
<br>=C2=A0 =C2=A0 =C2=A0Table t{};
<br>=C2=A0 =C2=A0 =C2=A0for (auto i =3D 0; i &lt; size; i++) {
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0const auto angle =3D (i * pi2 / size)=
;
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0const auto s =3D const_sine(angle);
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0t[i] =3D 32767 * s;
<br>=C2=A0 =C2=A0 =C2=A0}
<br>=C2=A0 =C2=A0 =C2=A0return t;
<br>}
<br>
<br>extern const Table sine_table =3D makeTable();
<br>
<br></blockquote></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/f24eb175-3da2-4d8d-88b5-2265c0c79a77%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f24eb175-3da2-4d8d-88b5-2265c0c79a77=
%40isocpp.org</a>.<br />

------=_Part_6995_1600751633.1507600453184--

------=_Part_6994_1301681308.1507600453183--

.

--001a11492a1467c7ae055b27c049
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Oct 6, 2017 at 7:44 PM, Myriachan <myriachan@gmail.com> wrote:

> On Friday, October 6, 2017 at 2:03:17 PM UTC-7, Ville Voutilainen wrote:
>>
>> On 7 October 2017 at 00:02, Myriachan <myri...@gmail.com> wrote:
>> >
>> > This is one reason to allow overloading on constexpr parameters.  It
>> allows
>> > things like separating compile-time and runtime implementations.
>>
>>
>> There are other possible solutions than overloading on constexpr. This
>> paper http://open-std.org/JTC1/SC22/WG21/docs/papers/2017/p0595r0.html
>> shows one of them.
>>
>
> Would also work!
>

Another interesting approach is to support (integral) fixed point in the
STL, and use something like

    constexpr auto x =3D std::atan_constexpr(std::fp_constant_q<A,B>);

or in general

    constexpr auto x =3D
std::some_function_consexpr(std::integral_constant<X>);

as an alternative to constexpr args; functions are actually templates

template <class T>
auto some_function(T)
{
    return ...expression(T::value);
}


> --
> 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/fcea9062-9094-498e-
> 8b30-98bc9186e85d%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/fcea9062-90=
94-498e-8b30-98bc9186e85d%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>



--=20
Who=E2=80=99s got the sweetest disposition?
One guess, that=E2=80=99s who?
Who=E2=80=99d never, ever start an argument?
Who never shows a bit of temperament?
Who's never wrong but always right?
Who'd never dream of starting a fight?
Who get stuck with all the bad luck?

--=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/CAFdMc-0S-gntvB5TRpcYscv3Sd_NnSYNp4dgUmWFA0XzXrA=
EFw%40mail.gmail.com.

--001a11492a1467c7ae055b27c049
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Fri, Oct 6, 2017 at 7:44 PM, Myriachan <span dir=3D"ltr">&lt;<a href=
=3D"mailto:myriachan@gmail.com" target=3D"_blank">myriachan@gmail.com</a>&g=
t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Frid=
ay, October 6, 2017 at 2:03:17 PM UTC-7, Ville Voutilainen wrote:<span clas=
s=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8e=
x;border-left:1px #ccc solid;padding-left:1ex">On 7 October 2017 at 00:02, =
Myriachan &lt;<a rel=3D"nofollow">myri...@gmail.com</a>&gt; wrote:
<br>&gt;
<br>&gt; This is one reason to allow overloading on constexpr parameters.=
=C2=A0 It allows
<br>&gt; things like separating compile-time and runtime implementations.
<br>
<br>
<br>There are other possible solutions than overloading on constexpr. This
<br>paper <a href=3D"http://open-std.org/JTC1/SC22/WG21/docs/papers/2017/p0=
595r0.html" rel=3D"nofollow" target=3D"_blank">http://open-std.org/JTC1/SC2=
2/<wbr>WG21/docs/papers/2017/p0595r0.<wbr>html</a>
<br>shows one of them.
<br></blockquote><div><br></div></span><div>Would also work! <br></div></di=
v></blockquote><div><br></div><div>Another interesting approach is to suppo=
rt (integral) fixed point in the STL, and use something like</div><div><br>=
</div><div>=C2=A0 =C2=A0 constexpr auto x =3D std::atan_constexpr(std::fp_c=
onstant_q&lt;A,B&gt;);</div><div><br></div><div>or in general</div><div><br=
></div><div>=C2=A0 =C2=A0 constexpr auto x =3D std::some_function_consexpr(=
std::integral_constant&lt;X&gt;);</div><div><br></div><div>as an alternativ=
e to constexpr args; functions are actually templates</div><div><br></div><=
div>template &lt;class T&gt;</div><div>auto some_function(T)</div><div>{</d=
iv><div>=C2=A0 =C2=A0 return ...expression(T::value);</div><div>}</div><div=
>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div></div></d=
iv><span class=3D"">

<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" 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></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/fcea9062-9094-498e-8b30-98bc9186e85d%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/fcea=
9062-9094-498e-<wbr>8b30-98bc9186e85d%40isocpp.org</a><wbr>.<br>
</blockquote></div><br><br clear=3D"all"><div><br></div>-- <br><div class=
=3D"gmail_signature" data-smartmail=3D"gmail_signature">Who=E2=80=99s got t=
he sweetest disposition?<br>One guess, that=E2=80=99s who?<br>Who=E2=80=99d=
 never, ever start an argument?<br>Who never shows a bit of temperament?<br=
>Who&#39;s never wrong but always right?<br>Who&#39;d never dream of starti=
ng a fight?<br>Who get stuck with all the bad luck? </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/CAFdMc-0S-gntvB5TRpcYscv3Sd_NnSYNp4dg=
UmWFA0XzXrAEFw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFdMc-0S-gntvB5T=
RpcYscv3Sd_NnSYNp4dgUmWFA0XzXrAEFw%40mail.gmail.com</a>.<br />

--001a11492a1467c7ae055b27c049--

.

--001a11423ea4bb90cd055b3337be
Content-Type: text/plain; charset="UTF-8"

On Mon, Oct 9, 2017 at 9:54 PM, FrankHB1989 <frankhb1989@gmail.com> wrote:
>
> Is it rounded?.
> IIRC it is 3.141592653589793238462643383279502884197169399...
>

The requirement (or perhaps hope) is that the double value contains the
closest representable value to the decimal.  If the decimal value is exactly
halfway between two representable values, there is a tiebreaker rule (I
think the value with LSB 0 is chosen.)

For each possible double value, there is a decimal value with no more than
17 significant digits that is closer to that double value than to any
other, so
there is no need to provide decimal constants written with more than 17
significant digits.  Supplying extra digits gives the illusion of more
precision
than the format supports.  It's misleading to code readers.

Going in the other direction, every decimal value with no more than 15
significant digits can be represented as a unique double value.

For floats, the equivalent numbers are 9 and 6; that is, every float value
has a decimal value with no more than 9 significant digits that is closer
to it than to any other value, and every decimal value with no more than
6 significant digits can be represented as a unique float value.

--
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/CAHSYqda%2B97dHGiYOmJNOxYbA7gegKQS5m%2BSCwL5bkhF%2BTsQXxg%40mail.gmail.com.

--001a11423ea4bb90cd055b3337be
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Oct 9, 2017 at 9:54 PM, FrankHB1989 <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:frankhb1989@gmail.com" target=3D"_blank">frankhb1989@gmail.com</a>&gt;=
</span> wrote:<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>Is it ro=
unded?.</div><div>IIRC it is 3.<wbr>141592653589793238462643383279<wbr>5028=
84197169399...</div></div></blockquote><div><br>The requirement (or perhaps=
 hope) is that the double value contains the<br>closest representable value=
 to the decimal.=C2=A0 If the decimal value is exactly<br>halfway between t=
wo representable values, there is a tiebreaker rule (I<br>think the value w=
ith LSB 0 is chosen.)<br><br>For each possible double value, there is a dec=
imal value with no more than<br>17 significant digits that is closer to tha=
t double value than to any other, so<br>there is no need to provide decimal=
 constants written with more than 17<br>significant digits.=C2=A0 Supplying=
 extra digits gives the illusion of more precision<br>than the format suppo=
rts.=C2=A0 It&#39;s misleading to code readers.</div><div><br></div><div>Go=
ing in the other direction, every decimal value with no more than 15<br>sig=
nificant digits can be represented as a unique double value.<br><br>For flo=
ats, the equivalent numbers are 9 and 6; that is, every float value<br>has =
a decimal value with no more than 9 significant digits that is closer<br>to=
 it than to any other value, and every decimal value with no more than<br>6=
 significant digits can be represented as a unique float value.</div></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/CAHSYqda%2B97dHGiYOmJNOxYbA7gegKQS5m%=
2BSCwL5bkhF%2BTsQXxg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqda%2B=
97dHGiYOmJNOxYbA7gegKQS5m%2BSCwL5bkhF%2BTsQXxg%40mail.gmail.com</a>.<br />

--001a11423ea4bb90cd055b3337be--

.