220 40461 article Path: news.gmane.org!.POSTED!not-for-mail From: Brian Bi Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Optional fixed point arithmetic was standardised into C in 2008. Why doesn't C++ adopt it? Date: Tue, 9 Oct 2018 14:16:34 -0500 Lines: 192 Approved: news@gmane.org Message-ID: References: <1f9ce37e-8a55-4e48-8f84-6ace99617160@isocpp.org> <089a9b4a-5793-49e5-bc5f-ccbd1b2de2af@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000036dd4b0577d09488" X-Trace: blaine.gmane.org 1539112482 1490 195.159.176.226 (9 Oct 2018 19:14:42 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 9 Oct 2018 19:14:42 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDS5ZX5VU4NBBIH56POQKGQE7EKD5PA@isocpp.org Tue Oct 09 21:14:38 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ed1-f70.google.com ([209.85.208.70]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1g9xSo-0000Hx-6T for gclcip-std-proposals@m.gmane.org; Tue, 09 Oct 2018 21:14:38 +0200 Original-Received: by mail-ed1-f70.google.com with SMTP id x10-v6sf1838085edx.9 for ; Tue, 09 Oct 2018 12:16:49 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1539112609; cv=pass; d=google.com; s=arc-20160816; b=IcG1Z33ahcwoQ6ef1+JE+x93gR4IcWpj62SBmFfcq0oIrki4OpJXoqP+C379koobTn +tBLUiSxRJRlWSjTceo5+jS9FD1CXgtJrWSMcHqEYoJBzzI607iwBftCaaRleTZYLl05 jypkHgFfjY62UMTivxKSo1DvVBHpdVz62XInreuyENbHKApbaojrfq1GJ1Soisf2VZbe zmB3/bXpbDzakGMYwUl40F3KBy+7snBM0vU1xjfXjIn09X4X4L3C59sW6UcKdmQUleFB amaLWc9cV1qFfHtaRCgJ8MxhnKROQaJXIVMsQmmO8QtcrcVMIU72xsnSfJAcGciW5Cjq /o5A== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:to:subject:message-id:date :from:in-reply-to:references:mime-version:dkim-signature; bh=MH6+EbeehKX05SEWKM1gX/qe7EXBJHl8puaq2m7gbkQ=; b=UL3Km179MjhqPT+whYwzcFg/2v78KBSArgsBAJHM8mOeI1KPyPvYDgIEoJLoaiRsX1 RuxyY4guQ6suw32ybX8U7Fhvu6fl9zmzuXDyGJZQiHz5wUQA3RNlI1nuRdEUFg8tteU1 Du9RiGU/djWaJjS1Kx4fBBZuik1ECLQcuIYz/cavOCYLUeu4PBDMoIrZ2uNOLe9/W7Ly FP6qtphDXoZHwFjBrXl0B7Tgxoo1HX8LvFC5QqpHCuwOVvexgdL3a0rID5REdVOSwQoN CPfoJ5bwEH5oMnrBkAa2pQnBRHj7F4iDyjilhl26qMKPOekrfFoJZPCP0+LUM0OWMZlz zCAw== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=kdVbeCeX; spf=pass (google.com: domain of bbi5291@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=bbi5291@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=MH6+EbeehKX05SEWKM1gX/qe7EXBJHl8puaq2m7gbkQ=; b=s28iSruhPbzugGkxJ3oXC1hD35y8AlB6GgtzhSRdRGVoOYswkFSmyk8UwytTyMwTfV rYcztQywczSwIb97t7iGBKOcpkJrNwQh3RNux3xgEHbGb9mAZWNtErTGwg5TkYTcIk98 cSD/giaZXgD7FJCxSNxylZIBuy37IcjC7BZ0UtSOltg6//M0bEPpcTMDk9OHchpFVwI4 NMUAJEumAM3c+wp9mqZpd3ZIPc9DUvG2uz7PFl+aTewM6BsfG1L1xZjMfqNNvharc5/A h7DLOESIImxRBTNfzFw+37zs3418doeHZRUW9nHZVVS16/JqDZpmUkkZ/LeWRuhSDdI2 lQhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=MH6+EbeehKX05SEWKM1gX/qe7EXBJHl8puaq2m7gbkQ=; b=SJwCf9KOyLyPYkN1fP0zWVXIJxjcbvMVUJQU7EU+EZEqnr2R/azsFUsjH3ezL0d6dD vv0aQTCHDWLZjZGWO4evvIztellpYmPVqCICkrSn6DmES9qKMSNnqBBg+z8eimCQE+9D lZvWN3+FyKlY6LyESFRbXkCSrBf2+bB3NTJKIPt7VtVC5lnLp7ZI/WBu9eGjoyHY1nck g2kMARkxU4WTtlL1H4uCzVjc7IbBF49oKajM23JzbYvTj/16tkQCkT7VAGio2nwwdM6j DlyqXVf1s/r7Z5V+/8fDHQWxIDvGJh5W8GdgKLaDIpwTpinfYRh/Qc6h2vOexQWtmQ2X D2Ng== X-Gm-Message-State: ABuFfojcXx3b2MiJWgb1bw+gX06hiyQv3kdeorBkudIbjP0SRTj9Fywg d6S/nm7oZBrWup8vuYQHIrdRYA== X-Google-Smtp-Source: ACcGV63AdhtNbDMv99VMbBTfSTgg4+jOe7s0g7JAezlC4Lg7quaKWLeRCnyp9tw6yHJVLUaU6F8jxw== X-Received: by 2002:aa7:c385:: with SMTP id k5-v6mr2449299edq.1.1539112608914; Tue, 09 Oct 2018 12:16:48 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a17:906:c7c5:: with SMTP id dc5-v6ls1191201ejb.7.gmail; Tue, 09 Oct 2018 12:16:47 -0700 (PDT) X-Received: by 2002:a17:906:71c3:: with SMTP id i3-v6mr29498315ejk.37.1539112607734; Tue, 09 Oct 2018 12:16:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1539112607; cv=none; d=google.com; s=arc-20160816; b=JNSkiYVCOpDPHYjxUWp1vX2+dEpawcOE8DbUkzmW2XHghJd9paXYtqGQsl45dm5MCD mSPoNVO67ag3+dJtTFKkC92qFLTEhoZaD6640a9trWnWnEPqqXyFaz2qf09CHjjdBnZp nuGe2O0sxPGqYeQAj/Iucv2bhdibJ1D0QWutRtGt3pr5S5pvQjGOsQcuK6nie+bLCsG/ K32oqMbeFJhXar5W4j4vxsdmUU2swrZNnswmHLFl1tYm5gBq/i5r6xu2dw85iuaw+jYe ARhMrUJ5z2dmWW4K6LzEkAZhtj9dJ5tGPXFXDHhn5k81HFXbytOq2mmr4dIiLnQxu3zU Km6Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=Vv6hFUrcEdQNGWPevo9vyt5WMYrIEfDMYq+bNAaytXs=; b=GwEsJraUIJnq+waHoJAsh12mIe4ZnJvzntR/IhgTY9kqoEun8dcgiqGMV6rM6x7LME wS1Hp1vpDgeviyDu+wSAFWgnyzKRJ7ZMK9MKM8ZGsKR3XBtiL+1SYxQa88R4OJlV745y DkgCWP92RKQZ5Gbah1fJdOuZ+qxI7ghO5Yt8Sk7G1Bd3OeDqMXLrJZBlV/C5aFRUJdQi bScNDIFVpgWKqvrbqW/W0M+xWDjz7qRjBIm2UN+uDXC2GGpuL+o249tbdpBHSF/TiTcY hxiS6Ces/OqSTw6JnLi66/bBoMaHke0agcsa0uyZHPveP/ZAdxyfYmAAbbHL5RAh9mUd ctCw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=kdVbeCeX; spf=pass (google.com: domain of bbi5291@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=bbi5291@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Original-Received: from mail-sor-f41.google.com (mail-sor-f41.google.com. [209.85.220.41]) by mx.google.com with SMTPS id e19-v6sor16250363edq.17.2018.10.09.12.16.47 for (Google Transport Security); Tue, 09 Oct 2018 12:16:47 -0700 (PDT) Received-SPF: pass (google.com: domain of bbi5291@gmail.com designates 209.85.220.41 as permitted sender) client-ip=209.85.220.41; X-Received: by 2002:a50:e699:: with SMTP id z25-v6mr36479331edm.275.1539112607078; Tue, 09 Oct 2018 12:16:47 -0700 (PDT) In-Reply-To: <089a9b4a-5793-49e5-bc5f-ccbd1b2de2af@isocpp.org> X-Original-Sender: bbi5291@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=kdVbeCeX; spf=pass (google.com: domain of bbi5291@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=bbi5291@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:40461 Archived-At: --00000000000036dd4b0577d09488 Content-Type: text/plain; charset="UTF-8" On Tue, Oct 9, 2018 at 2:08 PM 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 >> 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 > > . > -- *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
On Tue, Oct 9,= 2018 at 2:08 PM Niall Douglas <nialldouglas14@gmail.com> wrote:
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's a fairly high bar, in my opinion, to meet when essen= tially 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 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.


<= /blockquote>
Here's a brief mention of N1169:
http://www.open-std.org/jtc1/sc22/wg21/d= ocs/papers/2018/p0037r5.html#N1169
I'm not sure it's ever co= me up before. I assumed the advantages of parameterizing exponent were fair= ly 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 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.
=
To my even more inexperienced and untrained eye, the fixed s= et of types in N1169 is because C doesn'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
=C2=A0

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=C2=A0as being empirically inferior to whatever approach is bein= g proposed.

I'll put this another way. If the = Elsewhere Memory SG is approved, it'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's what the= SG ends up choosing). After all, LLVM and other compilers already implemen= t N1169, there is plenty of empirical experience, and it's an ISO st= andard. 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 refute<= /i>=C2=A0the current approach, ideally empirically.
=
I'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't even persuasive (let alone presumptive) evide= nce that C++ would be best served by a similar approach.
=C2=A0

Does that make sense= ? If it does, that's my concern. I'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'd = consider that having freeform exponents has no cost, and all is rosy and da= ndy.

Niall

--
You received this message because you are subscribed to the Google Groups &= quot;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/089a9b4a-5793-= 49e5-bc5f-ccbd1b2de2af%40isocpp.org.


--
Brian Bi

--
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit h= ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAMmfjbN16Z4p_w= 4M9zGM4cn5Urup4gserHT%2Bn88XSOv-imhP2w%40mail.gmail.com.
--00000000000036dd4b0577d09488-- .