220 40460 <089a9b4a-5793-49e5-bc5f-ccbd1b2de2af@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Niall Douglas 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 12:08:55 -0700 (PDT) Lines: 134 Approved: news@gmane.org Message-ID: <089a9b4a-5793-49e5-bc5f-ccbd1b2de2af@isocpp.org> References: <1f9ce37e-8a55-4e48-8f84-6ace99617160@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_2529_546787761.1539112135737" X-Trace: blaine.gmane.org 1539112012 29770 195.159.176.226 (9 Oct 2018 19:06:52 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 9 Oct 2018 19:06:52 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDGKFT5YZADRBSHZ6POQKGQEZBBJSCY@isocpp.org Tue Oct 09 21:06:47 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yw1-f70.google.com ([209.85.161.70]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1g9xLD-0007d1-Mm for gclcip-std-proposals@m.gmane.org; Tue, 09 Oct 2018 21:06:47 +0200 Original-Received: by mail-yw1-f70.google.com with SMTP id w8-v6sf1545633ywa.21 for ; Tue, 09 Oct 2018 12:08:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=ejRLGn5419UBM2c4CkZu/g4jp2Tf/PIAGl9qBOD3GVY=; b=L+EYnpLdjd3ighQNJyEU66jvuP7etF5Db6g2hwF4aTX3Y3cbcsAA9MLzoAhme5HNlH 0rYkMuyEPmYujNzI+6NfoT2xZmsrc8ZH+z5L2M23HB0GxmPkgcZqsh68GGwh+HwGDfja 0G3Vz6gnjX99WHn4js6jWuBV0S1ZNmbmPRHLNZ+M9wLaV1neyJGJxsbD/BFjYNHT6Kll DzuRGBIfSf2dCAKN+4o8ErWpJ7f6ShZt31QPYEFVTJhty0ADOqQeLdiqXhwjnfDdB/m2 pTWKrYFgHgyjnC2jEUQ4ZUtPz2/fAJlQkxj2UCo9GLnlzK4liUNk279fDp+FECDQ5rmu uY9Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=ejRLGn5419UBM2c4CkZu/g4jp2Tf/PIAGl9qBOD3GVY=; b=RbpGo5VuzLxBMjmDC0LkfkMBF/lnF3EP6y5UyiMshfcTp40ROMg6dWoBeAhXZYmsRb I3pP3KGweP5x9bChAa1v91sbzeRBmCsjGwt/QTOSACxMC/N8W9IjlIbacwqM2zHG5mEL eyi0hg2BUmXt/xDNaeX/mQhLjlQfkYpxCasxk3AVYOvTb41DX+4nxmnhzhtmrioT4/7N bT0sCozqJ/261Qb3J/KeUmvBV/aHhNSOlCpTNq0rkebhFFVvFowatr50a/6aSTHWainX C8APCthdGHNfFchkNCQTWJYrGXS5IN0wngfifGqJvRgGT42pyrbKpBbKSchDp8afq2EQ ilDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:x-original-sender:reply-to:precedence :mailing-list:list-id:x-spam-checked-in-group:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=ejRLGn5419UBM2c4CkZu/g4jp2Tf/PIAGl9qBOD3GVY=; b=d1eZEcdaUAhyDTzlHzcYIdSbp1y2PtV9c0+Ssxsq/Kpt/X+fsc15RubRCiVkCSi8fI 9e/HR32ZclUZcHuuEiu/UliV2yvHZf44nK5FFHEF97NibFHga/qrNNe2wMouk12KXlhc 0LyZHZBa+3au/lhi9a/hhU5EbqKA4xO8FMzyUPUmAFcRHSTBtNZEDZaRrz7YGFX5w8I7 6DdGuyGVakeLu3OwynAlJqSN/U0vU3npMZSQRPYKnpN57lt3v4zG4nI3boKb3Ec35gsw FEHGKbqQeHyJ8xTm4n+12u/kaHFIXewjBdQNSfQmM9NKQcirS9bD3PR0jIT2/R1W+fIV WnNQ== X-Gm-Message-State: ABuFfoixlLj1Mbl6KJXxnz3rDKHrXKWThq1/ugJ3opQJmcRwARQAxt2g RghuTE9I2LyT8vNhxdOONr93TA== X-Google-Smtp-Source: ACcGV61XDXF6W8y7LuLokkcXmiDEymM5comXKkQCTICBL6SoCwphEcbfO2M2YEdLDzRAWg/eJu11Ug== X-Received: by 2002:a81:7c88:: with SMTP id x130-v6mr16465002ywc.18.1539112137823; Tue, 09 Oct 2018 12:08:57 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a81:5244:: with SMTP id g65-v6ls499972ywb.3.gmail; Tue, 09 Oct 2018 12:08:56 -0700 (PDT) X-Received: by 2002:a0d:ea0b:: with SMTP id t11-v6mr325959ywe.6.1539112136346; Tue, 09 Oct 2018 12:08:56 -0700 (PDT) In-Reply-To: X-Original-Sender: nialldouglas14@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:40460 Archived-At: ------=_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
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's a fairly high bar, in my opinion, to meet when essential= ly 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 doma= in expertise in fixed point arithmetic, I could go away feeling satisfied W= G21 is on the right track on this.


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

Thanks for the links.

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.

Now if I'm totally w= rong on that, then that's great to learn. But I don't think P0037 o= r P0106 can just hand wave N1169 away like they do. N1169 ought to be re= futed=C2=A0as being empirically inferior to whatever approach is being = proposed.

I'll put this another way. If the El= sewhere Memory SG is approved, it'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's what the S= G ends up choosing). After all, LLVM and other compilers already implement = N1169, there is plenty of empirical experience, and it's an ISO stan= dard. 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 refute=C2=A0the current approach, ideally empirically.

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

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-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 https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/089a9b4a-5793-49e5-bc5f-ccbd1b2de2af= %40isocpp.org.
------=_Part_2530_95653460.1539112135738-- ------=_Part_2529_546787761.1539112135737-- .