On Mon, 8 Oct 2018 at 21:25, Niall Douglas <nialldouglas14@gmail.com> wrote:
>
> So, learned something new from WG14 today, namely that C standardised optional fixed point arithmetic back in 2004, with a second edition in 2008. I didn't know that before. Here is a pre-publication draft of the standard ISO/IEC TR 18037:2008:
>
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1169.pdf
>
> Why doesn't WG21 simply adopt this instead of the (library) fixed point arithmetic proposals currently before it?

Probably for the same reason why complex is a library type in C++;
WG21 thinks it can do better with a library approach than
with a built-in one.

--
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/CAFk2RUY%2BQC2NN5qiSzyn_rOvJfY-B4F3t3RqJrUZVA2Jvmd77g%40mail.gmail.com.

.

------=_Part_390_985588182.1539027927582
Content-Type: multipart/alternative;
 boundary="----=_Part_391_746561743.1539027927583"

------=_Part_391_746561743.1539027927583
Content-Type: text/plain; charset="UTF-8"


>
> > So, learned something new from WG14 today, namely that C standardised
> optional fixed point arithmetic back in 2004, with a second edition in
> 2008. I didn't know that before. Here is a pre-publication draft of the
> standard ISO/IEC TR 18037:2008:
> >
> > http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1169.pdf
> >
> > Why doesn't WG21 simply adopt this instead of the (library) fixed point
> arithmetic proposals currently before it?
>
> Probably for the same reason why complex is a library type in C++;
> WG21 thinks it can do better with a library approach than
> with a built-in one.
>

Well, sure. But I really wish the authors of the relevant papers before
WG21 described in their motivation why they think that a library approach
is clearly superior to an already published standard. That's a fairly high
bar, in my opinion, to meet when essentially proposing "I don't think the
standardised way is sufficient for reasons A, B and C. Here's what I
propose instead ...". And I don't remember such explanatory text in
motivations. I was hoping somebody could link me to such a text, I could
read it, and as someone without domain expertise in fixed point arithmetic,
I could go away feeling satisfied WG21 is on the right track on this.

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/1f9ce37e-8a55-4e48-8f84-6ace99617160%40isocpp.org.

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

<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;">&gt; So, learned something new=
 from WG14 today, namely that C standardised optional fixed point arithmeti=
c back in 2004, with a second edition in 2008. I didn&#39;t know that befor=
e. Here is a pre-publication draft of the standard ISO/IEC TR 18037:2008:
<br>&gt;
<br>&gt; <a href=3D"http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1169.p=
df" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http=
://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg=
14%2Fwww%2Fdocs%2Fn1169.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGfSrA39=
IJzox4tATMeVx-OowCCBQ&#39;;return true;" onclick=3D"this.href=3D&#39;http:/=
/www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg14=
%2Fwww%2Fdocs%2Fn1169.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGfSrA39IJ=
zox4tATMeVx-OowCCBQ&#39;;return true;">http://www.open-std.org/jtc1/<wbr>sc=
22/wg14/www/docs/n1169.pdf</a>
<br>&gt;
<br>&gt; Why doesn&#39;t WG21 simply adopt this instead of the (library) fi=
xed point arithmetic proposals currently before it?
<br>
<br>Probably for the same reason why complex is a library type in C++;
<br>WG21 thinks it can do better with a library approach than
<br>with a built-in one.
<br></blockquote><div><br></div><div>Well, sure. But I really wish the auth=
ors of the relevant papers before WG21 described in their motivation why th=
ey think that a library approach is clearly superior to an already publishe=
d standard. That&#39;s a fairly high bar, in my opinion, to meet when essen=
tially proposing &quot;I don&#39;t think the standardised way is sufficient=
 for reasons A, B and C. Here&#39;s what I propose instead ...&quot;. And I=
 don&#39;t remember such explanatory text in motivations. I was hoping some=
body could link me to such a text, I could read it, and as someone without =
domain expertise in fixed point arithmetic, I could go away feeling satisfi=
ed WG21 is on the right track on this.</div><div><br></div><div>Niall</div>=
<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/1f9ce37e-8a55-4e48-8f84-6ace99617160%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1f9ce37e-8a55-4e48-8f84-6ace99617160=
%40isocpp.org</a>.<br />

------=_Part_391_746561743.1539027927583--

------=_Part_390_985588182.1539027927582--

.

--000000000000f837b50577d042fc
Content-Type: text/plain; charset="UTF-8"

On Mon, Oct 8, 2018, 20:45 Niall Douglas <nialldouglas14@gmail.com> wrote:

> > So, learned something new from WG14 today, namely that C standardised
>> optional fixed point arithmetic back in 2004, with a second edition in
>> 2008. I didn't know that before. Here is a pre-publication draft of the
>> standard ISO/IEC TR 18037:2008:
>> >
>> > http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1169.pdf
>> >
>> > Why doesn't WG21 simply adopt this instead of the (library) fixed point
>> arithmetic proposals currently before it?
>>
>> Probably for the same reason why complex is a library type in C++;
>> WG21 thinks it can do better with a library approach than
>> with a built-in one.
>>
>
> Well, sure. But I really wish the authors of the relevant papers before
> WG21 described in their motivation why they think that a library approach
> is clearly superior to an already published standard. That's a fairly high
> bar, in my opinion, to meet when essentially proposing "I don't think the
> standardised way is sufficient for reasons A, B and C. Here's what I
> propose instead ...". And I don't remember such explanatory text in
> motivations. I was hoping somebody could link me to such a text, I could
> read it, and as someone without domain expertise in fixed point arithmetic,
> I could go away feeling satisfied WG21 is on the right track on this.
>
> Niall
>

Here's a brief mention of N1169:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0037r5.html#N1169
I'm not sure it's ever come up before. I assumed the advantages of
parameterizing exponent were fairly obvious.

>
> --
> 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/1f9ce37e-8a55-4e48-8f84-6ace99617160%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1f9ce37e-8a55-4e48-8f84-6ace99617160%40isocpp.org?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/CABPJVnT71yWK6NOU2G80CM%3Doe2E_m%2BkX58MfML%2BYA%3DcYRfZeQw%40mail.gmail.com.

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

<div>On Mon, Oct 8, 2018, 20:45 Niall Douglas &lt;<a href=3D"mailto:nialldo=
uglas14@gmail.com">nialldouglas14@gmail.com</a>&gt; wrote:</div><div class=
=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class=3D"gmail_=
quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddi=
ng-left:1ex">&gt; So, learned something new from WG14 today, namely that C =
standardised optional fixed point arithmetic back in 2004, with a second ed=
ition in 2008. I didn&#39;t know that before. Here is a pre-publication dra=
ft of the standard ISO/IEC TR 18037:2008:
<br>&gt;
<br>&gt; <a href=3D"http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1169.p=
df" rel=3D"nofollow" target=3D"_blank">http://www.open-std.org/jtc1/sc22/wg=
14/www/docs/n1169.pdf</a>
<br>&gt;
<br>&gt; Why doesn&#39;t WG21 simply adopt this instead of the (library) fi=
xed point arithmetic proposals currently before it?
<br>
<br>Probably for the same reason why complex is a library type in C++;
<br>WG21 thinks it can do better with a library approach than
<br>with a built-in one.
<br></blockquote><div><br></div><div>Well, sure. But I really wish the auth=
ors of the relevant papers before WG21 described in their motivation why th=
ey think that a library approach is clearly superior to an already publishe=
d standard. That&#39;s a fairly high bar, in my opinion, to meet when essen=
tially proposing &quot;I don&#39;t think the standardised way is sufficient=
 for reasons A, B and C. Here&#39;s what I propose instead ...&quot;. And I=
 don&#39;t remember such explanatory text in motivations. I was hoping some=
body could link me to such a text, I could read it, and as someone without =
domain expertise in fixed point arithmetic, I could go away feeling satisfi=
ed WG21 is on the right track on this.</div><div><br></div><div>Niall</div>=
</blockquote></div><div><br></div><div>Here&#39;s a brief mention of N1169:=
<br><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p003=
7r5.html#N1169">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p00=
37r5.html#N1169</a><br>I&#39;m not sure it&#39;s ever come up before. I ass=
umed the advantages of parameterizing exponent were fairly obvious.<br></di=
v><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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" target=3D"_=
blank">std-proposals+unsubscribe@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/1f9ce37e-8a55-4e48-8f84-6ace99617160%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1f9ce37e-8a55-=
4e48-8f84-6ace99617160%40isocpp.org</a>.<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/CABPJVnT71yWK6NOU2G80CM%3Doe2E_m%2BkX=
58MfML%2BYA%3DcYRfZeQw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CABPJVnT7=
1yWK6NOU2G80CM%3Doe2E_m%2BkX58MfML%2BYA%3DcYRfZeQw%40mail.gmail.com</a>.<br=
 />

--000000000000f837b50577d042fc--

.

--000000000000781a480577d04b88
Content-Type: text/plain; charset="UTF-8"

On Tue, Oct 9, 2018, 19:53 John McFarlane <john@mcfarlane.name> wrote:

> On Mon, Oct 8, 2018, 20:45 Niall Douglas <nialldouglas14@gmail.com> wrote:
>
>> > So, learned something new from WG14 today, namely that C standardised
>>> optional fixed point arithmetic back in 2004, with a second edition in
>>> 2008. I didn't know that before. Here is a pre-publication draft of the
>>> standard ISO/IEC TR 18037:2008:
>>> >
>>> > http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1169.pdf
>>> >
>>> > Why doesn't WG21 simply adopt this instead of the (library) fixed
>>> point arithmetic proposals currently before it?
>>>
>>> Probably for the same reason why complex is a library type in C++;
>>> WG21 thinks it can do better with a library approach than
>>> with a built-in one.
>>>
>>
>> Well, sure. But I really wish the authors of the relevant papers before
>> WG21 described in their motivation why they think that a library approach
>> is clearly superior to an already published standard. That's a fairly high
>> bar, in my opinion, to meet when essentially proposing "I don't think the
>> standardised way is sufficient for reasons A, B and C. Here's what I
>> propose instead ...". And I don't remember such explanatory text in
>> motivations. I was hoping somebody could link me to such a text, I could
>> read it, and as someone without domain expertise in fixed point arithmetic,
>> I could go away feeling satisfied WG21 is on the right track on this.
>>
>> Niall
>>
>
> Here's a brief mention of N1169:
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0037r5.html#N1169
> I'm not sure it's ever come up before. I assumed the advantages of
> parameterizing exponent were fairly obvious.
>

I nearly forgot: here's much the same conclusion being made in the other
C++ fixed-point proposal.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0106r0.html#prior_art

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/1f9ce37e-8a55-4e48-8f84-6ace99617160%40isocpp.org
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1f9ce37e-8a55-4e48-8f84-6ace99617160%40isocpp.org?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/CABPJVnSNtVyY-kp%2B2WjKKjSH7Arey-h36iuv8Ui%3Dv6uO9vBe4A%40mail.gmail.com.

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

<div class=3D"gmail_quote"><div dir=3D"ltr">On Tue, Oct 9, 2018, 19:53 John=
 McFarlane &lt;<a href=3D"mailto:john@mcfarlane.name">john@mcfarlane.name</=
a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On Mon, Oct 8, 2=
018, 20:45 Niall Douglas &lt;<a href=3D"mailto:nialldouglas14@gmail.com" ta=
rget=3D"_blank">nialldouglas14@gmail.com</a>&gt; wrote:</div><div class=3D"=
gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><blockquote class=3D"gmail_quot=
e" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-l=
eft:1ex">&gt; So, learned something new from WG14 today, namely that C stan=
dardised optional fixed point arithmetic back in 2004, with a second editio=
n in 2008. I didn&#39;t know that before. Here is a pre-publication draft o=
f the standard ISO/IEC TR 18037:2008:
<br>&gt;
<br>&gt; <a href=3D"http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1169.p=
df" rel=3D"nofollow" target=3D"_blank">http://www.open-std.org/jtc1/sc22/wg=
14/www/docs/n1169.pdf</a>
<br>&gt;
<br>&gt; Why doesn&#39;t WG21 simply adopt this instead of the (library) fi=
xed point arithmetic proposals currently before it?
<br>
<br>Probably for the same reason why complex is a library type in C++;
<br>WG21 thinks it can do better with a library approach than
<br>with a built-in one.
<br></blockquote><div><br></div><div>Well, sure. But I really wish the auth=
ors of the relevant papers before WG21 described in their motivation why th=
ey think that a library approach is clearly superior to an already publishe=
d standard. That&#39;s a fairly high bar, in my opinion, to meet when essen=
tially proposing &quot;I don&#39;t think the standardised way is sufficient=
 for reasons A, B and C. Here&#39;s what I propose instead ...&quot;. And I=
 don&#39;t remember such explanatory text in motivations. I was hoping some=
body could link me to such a text, I could read it, and as someone without =
domain expertise in fixed point arithmetic, I could go away feeling satisfi=
ed WG21 is on the right track on this.</div><div><br></div><div>Niall</div>=
</blockquote></div><div><br></div><div>Here&#39;s a brief mention of N1169:=
<br><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p003=
7r5.html#N1169" target=3D"_blank">http://www.open-std.org/jtc1/sc22/wg21/do=
cs/papers/2018/p0037r5.html#N1169</a><br>I&#39;m not sure it&#39;s ever com=
e up before. I assumed the advantages of parameterizing exponent were fairl=
y obvious.<br></div></blockquote></div><div><br></div><div>I nearly forgot:=
 here&#39;s much the same conclusion being made in the other C++ fixed-poin=
t proposal.</div><div><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/doc=
s/papers/2015/p0106r0.html#prior_art">http://www.open-std.org/jtc1/sc22/wg2=
1/docs/papers/2015/p0106r0.html#prior_art</a><br></div><div><br></div><div>=
John</div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div></=
div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br></di=
v>

<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@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/1f9ce37e-8a55-4e48-8f84-6ace99617160%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1f9ce37e-8a55-=
4e48-8f84-6ace99617160%40isocpp.org</a>.<br>
</blockquote></div>
</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/CABPJVnSNtVyY-kp%2B2WjKKjSH7Arey-h36i=
uv8Ui%3Dv6uO9vBe4A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CABPJVnSNtVyY=
-kp%2B2WjKKjSH7Arey-h36iuv8Ui%3Dv6uO9vBe4A%40mail.gmail.com</a>.<br />

--000000000000781a480577d04b88--

.

------=_Part_2529_546787761.1539112135737
Content-Type: multipart/alternative;
 boundary="----=_Part_2530_95653460.1539112135738"

------=_Part_2530_95653460.1539112135738
Content-Type: text/plain; charset="UTF-8"


>
> Well, sure. But I really wish the authors of the relevant papers before
>> WG21 described in their motivation why they think that a library approach
>> is clearly superior to an already published standard. That's a fairly high
>> bar, in my opinion, to meet when essentially proposing "I don't think the
>> standardised way is sufficient for reasons A, B and C. Here's what I
>> propose instead ...". And I don't remember such explanatory text in
>> motivations. I was hoping somebody could link me to such a text, I could
>> read it, and as someone without domain expertise in fixed point arithmetic,
>> I could go away feeling satisfied WG21 is on the right track on this.
>>
>>
>> Here's a brief mention of N1169:
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0037r5.html#N1169
> I'm not sure it's ever come up before. I assumed the advantages of
> parameterizing exponent were fairly obvious.
>

Thanks for the links.

Sure I get that freeform exponents are useful, but to my inexperienced and
untrained eye the fixed exponent choices in N1169 were because the codegen
would come out much cleaner, and in which I would assume it is therefore
faster and/or more predictable.

Now if I'm totally wrong on that, then that's great to learn. But I don't
think P0037 or P0106 can just hand wave N1169 away like they do. N1169
ought to be *refuted* as being empirically inferior to whatever approach is
being proposed.

I'll put this another way. If the Elsewhere Memory SG is approved, it's on
that SG to explain in its proposed changes to the C++ memory model to
support mapped memory why the multiple address spaces feature of N1169 was
not adopted (if that's what the SG ends up choosing). After all, LLVM and
other compilers already implement N1169, there is plenty of empirical
experience, and *it's an ISO standard*. Not following the currently
standard way of doing things in a standards proposal seems to me a high
claim to make - you need to *refute* the current approach, ideally
empirically.

Does that make sense? If it does, that's my concern. I'd like to see
side-by-side godbolt with clang showing N1169 output on one side, and
proposed standard output on the other, in which N1169 output is obviously
no better. Then I'd consider that having freeform exponents has no cost,
and all is rosy and dandy.

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/089a9b4a-5793-49e5-bc5f-ccbd1b2de2af%40isocpp.org.

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

<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><div class=3D"gmail_quote"><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex"><div>Well, sure. But I really wish the authors =
of the relevant papers before WG21 described in their motivation why they t=
hink that a library approach is clearly superior to an already published st=
andard. That&#39;s a fairly high bar, in my opinion, to meet when essential=
ly proposing &quot;I don&#39;t think the standardised way is sufficient for=
 reasons A, B and C. Here&#39;s what I propose instead ...&quot;. And I don=
&#39;t remember such explanatory text in motivations. I was hoping somebody=
 could link me to such a text, I could read it, and as someone without doma=
in expertise in fixed point arithmetic, I could go away feeling satisfied W=
G21 is on the right track on this.</div><div><br></div><div><br></div></blo=
ckquote></div><div>Here&#39;s a brief mention of N1169:<br><a href=3D"http:=
//www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0037r5.html#N1169" targ=
et=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.g=
oogle.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdoc=
s%2Fpapers%2F2018%2Fp0037r5.html%23N1169\x26sa\x3dD\x26sntz\x3d1\x26usg\x3d=
AFQjCNEVpSdOnK1tPKHJtsMIDlZoFJf4fA&#39;;return true;" onclick=3D"this.href=
=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1=
%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2018%2Fp0037r5.html%23N1169\x26sa\x3dD\x26=
sntz\x3d1\x26usg\x3dAFQjCNEVpSdOnK1tPKHJtsMIDlZoFJf4fA&#39;;return true;">h=
ttp://www.open-std.org/jtc1/<wbr>sc22/wg21/docs/papers/2018/<wbr>p0037r5.ht=
ml#N1169</a><br>I&#39;m not sure it&#39;s ever come up before. I assumed th=
e advantages of parameterizing exponent were fairly obvious.</div></blockqu=
ote><div><br></div><div>Thanks for the links.</div><div><br></div><div>Sure=
 I get that freeform exponents are useful, but to my inexperienced and untr=
ained eye the fixed exponent choices in N1169 were because the codegen woul=
d come out much cleaner, and in which I would assume it is therefore faster=
 and/or more predictable.</div><div><br></div><div>Now if I&#39;m totally w=
rong on that, then that&#39;s great to learn. But I don&#39;t think P0037 o=
r P0106 can just hand wave N1169 away like they do. N1169 ought to be <i>re=
futed</i>=C2=A0as being empirically inferior to whatever approach is being =
proposed.</div><div><br></div><div>I&#39;ll put this another way. If the El=
sewhere Memory SG is approved, it&#39;s on that SG to explain in its propos=
ed changes to the C++ memory model to support mapped memory why the multipl=
e address spaces feature of N1169 was not adopted (if that&#39;s what the S=
G ends up choosing). After all, LLVM and other compilers already implement =
N1169, there is plenty of empirical experience, and <i>it&#39;s an ISO stan=
dard</i>. Not following the currently standard way of doing things in a sta=
ndards proposal seems to me a high claim to make - you need to <i>refute</i=
>=C2=A0the current approach, ideally empirically.</div><div><br></div><div>=
Does that make sense? If it does, that&#39;s my concern. I&#39;d like to se=
e side-by-side godbolt with clang showing N1169 output on one side, and pro=
posed standard output on the other, in which N1169 output is obviously no b=
etter. Then I&#39;d consider that having freeform exponents has no cost, an=
d all is rosy and dandy.</div><div><br></div><div>Niall</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/089a9b4a-5793-49e5-bc5f-ccbd1b2de2af%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/089a9b4a-5793-49e5-bc5f-ccbd1b2de2af=
%40isocpp.org</a>.<br />

------=_Part_2530_95653460.1539112135738--

------=_Part_2529_546787761.1539112135737--

.

--00000000000036dd4b0577d09488
Content-Type: text/plain; charset="UTF-8"

On Tue, Oct 9, 2018 at 2:08 PM Niall Douglas <nialldouglas14@gmail.com>
wrote:

> Well, sure. But I really wish the authors of the relevant papers before
>>> WG21 described in their motivation why they think that a library approach
>>> is clearly superior to an already published standard. That's a fairly high
>>> bar, in my opinion, to meet when essentially proposing "I don't think the
>>> standardised way is sufficient for reasons A, B and C. Here's what I
>>> propose instead ...". And I don't remember such explanatory text in
>>> motivations. I was hoping somebody could link me to such a text, I could
>>> read it, and as someone without domain expertise in fixed point arithmetic,
>>> I could go away feeling satisfied WG21 is on the right track on this.
>>>
>>>
>>> Here's a brief mention of N1169:
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0037r5.html#N1169
>> I'm not sure it's ever come up before. I assumed the advantages of
>> parameterizing exponent were fairly obvious.
>>
>
> Thanks for the links.
>
> Sure I get that freeform exponents are useful, but to my inexperienced and
> untrained eye the fixed exponent choices in N1169 were because the codegen
> would come out much cleaner, and in which I would assume it is therefore
> faster and/or more predictable.
>

To my even more inexperienced and untrained eye, the fixed set of types in
N1169 is because C doesn't have templates and therefore has no easy way to
construct arbitrarily parametrized types like the proposed fixed-width
arithmetic library types for C++.


>
> Now if I'm totally wrong on that, then that's great to learn. But I don't
> think P0037 or P0106 can just hand wave N1169 away like they do. N1169
> ought to be *refuted* as being empirically inferior to whatever approach
> is being proposed.
>
> I'll put this another way. If the Elsewhere Memory SG is approved, it's on
> that SG to explain in its proposed changes to the C++ memory model to
> support mapped memory why the multiple address spaces feature of N1169 was
> not adopted (if that's what the SG ends up choosing). After all, LLVM and
> other compilers already implement N1169, there is plenty of empirical
> experience, and *it's an ISO standard*. Not following the currently
> standard way of doing things in a standards proposal seems to me a high
> claim to make - you need to *refute* the current approach, ideally
> empirically.
>

I'm not totally clear on what the current relationship is between ISO C and
ISO C++, but my understanding is that C and C++ have diverged in philosophy
to such an extent that the fact that something is done a certain way in C
isn't even persuasive (let alone presumptive) evidence that C++ would be
best served by a similar approach.


>
> Does that make sense? If it does, that's my concern. I'd like to see
> side-by-side godbolt with clang showing N1169 output on one side, and
> proposed standard output on the other, in which N1169 output is obviously
> no better. Then I'd consider that having freeform exponents has no cost,
> and all is rosy and dandy.
>
> 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/089a9b4a-5793-49e5-bc5f-ccbd1b2de2af%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/089a9b4a-5793-49e5-bc5f-ccbd1b2de2af%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>


--
*Brian Bi*

--
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/CAMmfjbN16Z4p_w4M9zGM4cn5Urup4gserHT%2Bn88XSOv-imhP2w%40mail.gmail.com.

--00000000000036dd4b0577d09488
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 Tue, Oct 9,=
 2018 at 2:08 PM Niall Douglas &lt;<a href=3D"mailto:nialldouglas14@gmail.c=
om">nialldouglas14@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"gmail_quote"=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div>Well, sure. But I really wish the auth=
ors of the relevant papers before WG21 described in their motivation why th=
ey think that a library approach is clearly superior to an already publishe=
d standard. That&#39;s a fairly high bar, in my opinion, to meet when essen=
tially proposing &quot;I don&#39;t think the standardised way is sufficient=
 for reasons A, B and C. Here&#39;s what I propose instead ...&quot;. And I=
 don&#39;t remember such explanatory text in motivations. I was hoping some=
body could link me to such a text, I could read it, and as someone without =
domain expertise in fixed point arithmetic, I could go away feeling satisfi=
ed WG21 is on the right track on this.</div><div><br></div><div><br></div><=
/blockquote></div><div>Here&#39;s a brief mention of N1169:<br><a href=3D"h=
ttp://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0037r5.html#N1169" =
rel=3D"nofollow" target=3D"_blank">http://www.open-std.org/jtc1/sc22/wg21/d=
ocs/papers/2018/p0037r5.html#N1169</a><br>I&#39;m not sure it&#39;s ever co=
me up before. I assumed the advantages of parameterizing exponent were fair=
ly obvious.</div></blockquote><div><br></div><div>Thanks for the links.</di=
v><div><br></div><div>Sure I get that freeform exponents are useful, but to=
 my inexperienced and untrained eye the fixed exponent choices in N1169 wer=
e because the codegen would come out much cleaner, and in which I would ass=
ume it is therefore faster and/or more predictable.</div></blockquote><div>=
<br></div><div>To my even more inexperienced and untrained eye, the fixed s=
et of types in N1169 is because C doesn&#39;t have templates and therefore =
has no easy way to construct arbitrarily parametrized types like the propos=
ed fixed-width arithmetic library types for C++.=C2=A0</div><div>=C2=A0</di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div><br></div><div>Now if I&#39;m totally=
 wrong on that, then that&#39;s great to learn. But I don&#39;t think P0037=
 or P0106 can just hand wave N1169 away like they do. N1169 ought to be <i>=
refuted</i>=C2=A0as being empirically inferior to whatever approach is bein=
g proposed.</div><div><br></div><div>I&#39;ll put this another way. If the =
Elsewhere Memory SG is approved, it&#39;s on that SG to explain in its prop=
osed changes to the C++ memory model to support mapped memory why the multi=
ple address spaces feature of N1169 was not adopted (if that&#39;s what the=
 SG ends up choosing). After all, LLVM and other compilers already implemen=
t N1169, there is plenty of empirical experience, and <i>it&#39;s an ISO st=
andard</i>. Not following the currently standard way of doing things in a s=
tandards proposal seems to me a high claim to make - you need to <i>refute<=
/i>=C2=A0the current approach, ideally empirically.</div></blockquote><div>=
<br></div><div>I&#39;m not totally clear on what the current relationship i=
s between ISO C and ISO C++, but my understanding is that C and C++ have di=
verged in philosophy to such an extent that the fact that something is done=
 a certain way in C isn&#39;t even persuasive (let alone presumptive) evide=
nce that C++ would be best served by a similar approach.</div><div>=C2=A0</=
div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><div><br></div><div>Does that make sense=
? If it does, that&#39;s my concern. I&#39;d like to see side-by-side godbo=
lt with clang showing N1169 output on one side, and proposed standard outpu=
t on the other, in which N1169 output is obviously no better. Then I&#39;d =
consider that having freeform exponents has no cost, and all is rosy and da=
ndy.</div><div><br></div><div>Niall</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" target=3D"_=
blank">std-proposals+unsubscribe@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/089a9b4a-5793-49e5-bc5f-ccbd1b2de2af%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/089a9b4a-5793-=
49e5-bc5f-ccbd1b2de2af%40isocpp.org</a>.<br>
</blockquote></div><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr"=
 class=3D"gmail_signature" data-smartmail=3D"gmail_signature"><div dir=3D"l=
tr"><div><div dir=3D"ltr"><font color=3D"#c0c0c0"><i>Brian Bi</i></font><br=
><div></div><div></div><div></div></div></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/CAMmfjbN16Z4p_w4M9zGM4cn5Urup4gserHT%=
2Bn88XSOv-imhP2w%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAMmfjbN16Z4p_w=
4M9zGM4cn5Urup4gserHT%2Bn88XSOv-imhP2w%40mail.gmail.com</a>.<br />

--00000000000036dd4b0577d09488--

.

On 08/10/18 20:25, Niall Douglas wrote:
> So, learned something new from WG14 today, namely that C standardised
> optional fixed point arithmetic back in 2004, with a second edition in
> 2008. I didn't know that before. Here is a pre-publication draft of the
> standard *ISO/IEC TR 18037:2008*:
>
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1169.pdf
>
> Why doesn't WG21 simply adopt this instead of the (library) fixed point
> arithmetic proposals currently before it?
>

Well, almost no C compilers support that standard - because almost no
one wants to use it.  The TR has 3 key areas that are supposed to
improve C programming in the embedded world.  It covers fixed-point
arithmetic in a way no one wants (especially not embedded programmers),
named address spaces that are underpowered, and hardware I/O that is not
needed, not useful, and contrary to the way every embedded compiler and
programmer handles it.

The TR for "C Extensions to support embedded processors" is a huge
disappointment, a result of a /total/ failure to look at the realities
of the industry in terms of what embedded toolchains provide and what
embedded programmers want, combined with an absurd time schedule.  While
the group behind this spend many years slowly writing the document in a
couple of versions, everyone in the embedded development industry got on
with their jobs.  So by the time it was published, it would have been
irrelevant even if it had been useful.

I only know of one compiler that has some implementation of this TR's
fixed point types - that is gcc, which implements it on some targets.  I
have tried it, and the code generated is hopeless despite the target
processor having support for some fixed point formats.  It is basically
a matter of a gcc developer in the past having implemented the front-end
parts and very basic code generation, presumably with the intention that
others would pick up the ball and turn it into more optimal code now
that the process had been started.  However, it has seen no interest
(AFAIK) from either compiler developers or users.

I haven't heard anything about a C++ standard library for fixed-point
arithmetic, but it would be very difficult to produce something worse
than this C "extension" TR that has been rightly ignored.



--
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/ppkc4l%246u0%241%40blaine.gmane.org.

.

On 09/10/18 21:08, Niall Douglas wrote:
>         Well, sure. But I really wish the authors of the relevant papers
>         before WG21 described in their motivation why they think that a
>         library approach is clearly superior to an already published
>         standard. That's a fairly high bar, in my opinion, to meet when
>         essentially proposing "I don't think the standardised way is
>         sufficient for reasons A, B and C. Here's what I propose instead
>         ...". And I don't remember such explanatory text in motivations.
>         I was hoping somebody could link me to such a text, I could read
>         it, and as someone without domain expertise in fixed point
>         arithmetic, I could go away feeling satisfied WG21 is on the
>         right track on this.
>
>
>     Here's a brief mention of N1169:
>     http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0037r5.html#N1169
>     <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0037r5.html#N1169>
>     I'm not sure it's ever come up before. I assumed the advantages of
>     parameterizing exponent were fairly obvious.
>
>
> Thanks for the links.
>
> Sure I get that freeform exponents are useful, but to my inexperienced
> and untrained eye the fixed exponent choices in N1169 were because the
> codegen would come out much cleaner, and in which I would assume it is
> therefore faster and/or more predictable.
>
> Now if I'm totally wrong on that, then that's great to learn. But I
> don't think P0037 or P0106 can just hand wave N1169 away like they do.
> N1169 ought to be /refuted/ as being empirically inferior to whatever
> approach is being proposed.

One of the biggest problems with the N1169 approach is that it has types
that have fixed but implementation-specified sizes.  This is completely
and totally useless to embedded programmers (or any other programmers
interested in fixed point).  It does not matter how efficient they are
implemented if no one knows what they are!

If you are programming in an embedded system, you want fixed point
numbers in the "Q" format.  (Sometimes people use different names, but
it is the same thing.)  You want something like Q4.12, which is a 16-bit
signed integer scaled by 2 ^ 12.  Or you want UQ0.8, which is an 8-bit
unsigned integer scaled by 2 ^ 8 - i.e., a number between 0 and just
under 1.  You need to know the exact range, and exact precision, and
exact size - N1169's "signed short _Fract", etc., are totally
meaningless.  It is /infinitely/ more important that you have the exact
sizes you want than that you have a type that can be implemented
efficiently on the target hardware.

For ordinary integers, embedded programmers use int16_t, uint32_t - they
don't use "int" or "short".

A solution that does not give you this level of control and this
information should be rejected out of hand.


I also think you are misunderstanding the state of N1169.  It is a TR
proposal that no one uses, with only a small part of it implemented on a
few toolchains.  It is not part of the C standards.  Rejecting it does
not mean throwing away useful work or implementations.


I haven't yet read through the linked C++ fixed point proposals.  But
one thing that would be nice to have in them is an encouragement for
implementations to have specialised cases of the templates with more
optimal code for their targets.  For example, on the AVR microcontroller
you would expect that Q2.6 multiplication be implemented with shifts and
masks from general code, but that Q1.7 would use inline assembly for the
"fractional multiply" instruction that many AVR devices support.  Then
developers can choose formats with most efficient implementations - but
their primary motivation for choice is the format needed for correct code.


>
> I'll put this another way. If the Elsewhere Memory SG is approved, it's
> on that SG to explain in its proposed changes to the C++ memory model to
> support mapped memory why the multiple address spaces feature of N1169
> was not adopted (if that's what the SG ends up choosing). After all,
> LLVM and other compilers already implement N1169, there is plenty of
> empirical experience, and /it's an ISO standard/. Not following the
> currently standard way of doing things in a standards proposal seems to
> me a high claim to make - you need to /refute/ the current approach,
> ideally empirically.
>
> Does that make sense? If it does, that's my concern. I'd like to see
> side-by-side godbolt with clang showing N1169 output on one side, and
> proposed standard output on the other, in which N1169 output is
> obviously no better. Then I'd consider that having freeform exponents
> has no cost, and all is rosy and dandy.
>
> 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/ppkd61%24itp%241%40blaine.gmane.org.

.

------=_Part_2700_709589725.1539193214218
Content-Type: multipart/alternative;
 boundary="----=_Part_2701_1485068716.1539193214218"

------=_Part_2701_1485068716.1539193214218
Content-Type: text/plain; charset="UTF-8"


>
>
> I only know of one compiler that has some implementation of this TR's
> fixed point types - that is gcc, which implements it on some targets.  I
> have tried it, and the code generated is hopeless despite the target
> processor having support for some fixed point formats.  It is basically
> a matter of a gcc developer in the past having implemented the front-end
> parts and very basic code generation, presumably with the intention that
> others would pick up the ball and turn it into more optimal code now
> that the process had been started.  However, it has seen no interest
> (AFAIK) from either compiler developers or users.
>
> Useful to learn, thanks.

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/2c65de99-b905-4253-b02c-5b78d0238643%40isocpp.org.

------=_Part_2701_1485068716.1539193214218
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>I only kn=
ow of one compiler that has some implementation of this TR&#39;s
<br>fixed point types - that is gcc, which implements it on some targets. =
=C2=A0I
<br>have tried it, and the code generated is hopeless despite the target
<br>processor having support for some fixed point formats. =C2=A0It is basi=
cally
<br>a matter of a gcc developer in the past having implemented the front-en=
d
<br>parts and very basic code generation, presumably with the intention tha=
t
<br>others would pick up the ball and turn it into more optimal code now
<br>that the process had been started. =C2=A0However, it has seen no intere=
st
<br>(AFAIK) from either compiler developers or users.
<br>
<br></blockquote><div>Useful to learn, thanks.</div><div><br></div><div>Nia=
ll=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/2c65de99-b905-4253-b02c-5b78d0238643%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2c65de99-b905-4253-b02c-5b78d0238643=
%40isocpp.org</a>.<br />

------=_Part_2701_1485068716.1539193214218--

------=_Part_2700_709589725.1539193214218--

.