220 40468 article Path: news.gmane.org!.POSTED!not-for-mail From: David Brown 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: Wed, 10 Oct 2018 10:29:56 +0200 Lines: 100 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: text/plain; charset="UTF-8" X-Trace: blaine.gmane.org 1539160080 20505 195.159.176.226 (10 Oct 2018 08:28:00 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 10 Oct 2018 08:28:00 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDP6R2XHXIARBDPR63OQKGQEVBUX4SY@isocpp.org Wed Oct 10 10:27:56 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-lj1-f199.google.com ([209.85.208.199]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gA9qV-0005DU-9X for gclcip-std-proposals@m.gmane.org; Wed, 10 Oct 2018 10:27:55 +0200 Original-Received: by mail-lj1-f199.google.com with SMTP id v1-v6sf1371535ljv.22 for ; Wed, 10 Oct 2018 01:30:06 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1539160205; cv=pass; d=google.com; s=arc-20160816; b=wOnJo/nLRFqBXukNZdvCQfeDGgcvUnvSkhxsbRmxonGUNH8T6DCs87WLjnrNEfos3s tfBqoU5KFvHLtsFvjns7Sp/JVY8B3OSr2BVQ1wR8LSGBtOJ58i6MSXfw2MqR1LBAlPSU +AsbKXUXeWH5ku8dMgC38T5zEGjHAxzll2NRPp2rO7Y/XotQH4W7SkQK8VoSxZt/aMbw EpWOlUJ7hfinu4ku/hr01lm/2YV9hcxxqRQOZopJV/5Ti+Icgr+Q3r9j+5X7Td+WcXF1 AFaqDoemSEsi9w6JIZxF5eFYGtFxxCRKG1gcHFIBGPiNL9RteUxwlx8jsdbJXLmbsv/e IhzQ== 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:in-reply-to:user-agent :mime-version:references:message-id:lines:date:subject:from:to :dkim-signature; bh=qA/88w3keqXqTw6bt/xZT47kguASfr1JaZhXjmrKRYw=; b=yvPWuQ5N4gWLCHjIfrJ986zNFke43YsTSwLUj6oqCVzVVfWO/QfTi87KaCOLSf7pqQ rFCfRw1GoTtdpDVjP8wWw5iOjaQRIEtTy4kxhv/7KuoYzeATjDQ2VkZrKK4i1Lgvgezw RTwcTT9Wt136GpK1PqmteUQy3QoXv++yK4p32pgL5dXuy2PI7uVlmeDvR8j8xvTMcIpH taXxAOcmNOkm+61xAntPc1lBbbyJf67G9jLomqTqzX3jwtsLHpRtERVOgSK/kqU5/q7g 4S+hmHORp2rrVXMieE+ose7TFqQlex3woVklB3MsIOKmflVp9KQPTxKw8EOBtvcav1Fy tYkQ== ARC-Authentication-Results: i=2; mx.google.com; spf=neutral (google.com: 195.159.176.226 is neither permitted nor denied by best guess record for domain of gclcip-std-proposals@m.gmane.org) smtp.mailfrom=gclcip-std-proposals@m.gmane.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=to:from:subject:date:lines:message-id:references:mime-version :user-agent:in-reply-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=qA/88w3keqXqTw6bt/xZT47kguASfr1JaZhXjmrKRYw=; b=WK4oG/8cVg56gNk50jsghrmbPSNCDD2mHgWVABp1XTQcRPyFpEd8lOdv9hLPjOzxG6 nkVyGttGK/qg13Bl+ZoDLFOg6/8NHbVrT00jfywlL0E3nASUnUzCBZ1jNCOEagwDFsBp VeLX4XYDk0YhL8WTm6z3aSyJOYI+ZJ9jeCDpWsOA5EZP2g603yDSisxSWvO4KIyVQJuR FPcbQZACnS7/8NH+Wdg6S++0K44atoRjx0aYekRQ5oCQ3y1tTzQ2ceVbLEeqHJY0BcBz Oyr0/nV0ocv79X2gUx77oxuKwtRdhVyBLgMyQ3vzc1fEts9Yt5OWnrfglrR1Nriu3S6B 8ONQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:date:lines:message-id:references :mime-version:user-agent:in-reply-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=qA/88w3keqXqTw6bt/xZT47kguASfr1JaZhXjmrKRYw=; b=ee/yyhHK+rIOVHD7YU+XXUntPMIYEwvtG/MqNEwjNCvJbxOd8ZXhHZ/371W2cNHl7W 5/RaZfFaEsvNOvgyNFTcM8TuOkZCaxCfKCerASYZI1uvNJ4aEfLKNV+1CnQDVdMaXAGd qF6iasAuIgHV2SkeXAGllAEkyB/nQ3rmGdO0rY7NgfX5Uk/TRlGLR0SMb87Zb3abMFnM Z7WjtfRGwb8u9AA/F3THWLK3inl9619p7MEo3e6coyYtZ22/Wv23JMxwoHqZGpPol/ek UJXBwSamJfIiD9v+xzfUNqz0UZx9GrROzpi2dm1Jy8U1+z2RIrGOG1v5EY2CI4SVyt8H 1gRw== X-Gm-Message-State: ABuFfohKA/+4RQeaPn9x+NQzu/c07TTrwOvAuLd3WilmnS5htUUlyGP5 TKzMyRO4sUO+RMGkKj+5gsY= X-Google-Smtp-Source: ACcGV60wIk6FmOcTTAehOOFgZvMOX2XmyRdT1XOyTIv3X4X0HBPZya5BtqCb2nOjnqlQS3KIVbgyLA== X-Received: by 2002:a2e:988f:: with SMTP id b15-v6mr937343ljj.14.1539160205895; Wed, 10 Oct 2018 01:30:05 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a19:978e:: with SMTP id z136-v6ls186902lfd.58.gmail; Wed, 10 Oct 2018 01:30:04 -0700 (PDT) X-Received: by 2002:a19:d3c4:: with SMTP id k187-v6mr18283693lfg.101.1539160204545; Wed, 10 Oct 2018 01:30:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1539160204; cv=none; d=google.com; s=arc-20160816; b=yiNSUjq8CbvI7nWUmiMSFEkzCXTVYSYlOYbTEB7WIfXSTqgyaQ+iVM028j2eJmuLY6 nppN+wlXkp78dHo3BX52AT2eM8h+ajqfOdZTA+5yBxf6fL1ASJVQsz104saDkbapfxmJ 5G1v4Q/m8B9P6rKxZE1sy+kj/sfruzoOJx6Zpf2OJhn3cY8WuTbzCRgDlzCfIkVUdYxd c5ghcW6rsbSv0N9sghXhsorE3VRPbvVXe5WkBoeLCxez26TzuKnk+TUB0zEFj56G8SPO IHmmTdFuOtp9Ezi0mcYlVKv+7xQcLvTm+JCNecOuHH3hvUxOCARF2Rhg4gMZICrU7lTR 3+IQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:user-agent:content-transfer-encoding:mime-version :references:message-id:lines:date:subject:from:to; bh=jwrQeOQ+ueJhiX5c33HHdXkXfDrdyLXcUQSXo4kqDN8=; b=LZwAowIe873wtw+oSZMyaEWul8BRKpdl152vIs4ZcluZBto7NwT6JxFdtMfFe8DI4k ccruFhjpZQ8T+C0ZVXOGmpwycvbkDhDozTlq4Tr6MT3ZqjnduM7irfREKTKSHuREZAOP /pmHkDfYWsK/u9IBKyDR8kxcUBJWE9GQpKUVC+nirJTkRFftT1udi8Y+n+h/lgD5v70j gvPKSj+qMZP73P3JzlrScYQuCJxkNz7QxUGysa7VUgHyukmkgzw2hxvpTIndbgQdzlQQ aJDvTZQvtAiSaNwJA4WlHtdlp44X76vFgwPLxAhsf7Tj5TGeXpYsJ9euLGDTrUNRktD5 g/Rg== ARC-Authentication-Results: i=1; mx.google.com; spf=neutral (google.com: 195.159.176.226 is neither permitted nor denied by best guess record for domain of gclcip-std-proposals@m.gmane.org) smtp.mailfrom=gclcip-std-proposals@m.gmane.org Original-Received: from blaine.gmane.org ([195.159.176.226]) by mx.google.com with ESMTPS id m16-v6si23606918ljg.33.2018.10.10.01.30.04 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 Oct 2018 01:30:04 -0700 (PDT) Received-SPF: neutral (google.com: 195.159.176.226 is neither permitted nor denied by best guess record for domain of gclcip-std-proposals@m.gmane.org) client-ip=195.159.176.226; Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1gA9qS-0005BM-Qp for std-proposals@isocpp.org; Wed, 10 Oct 2018 10:27:52 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 93 Original-X-Complaints-To: usenet@blaine.gmane.org In-Reply-To: <089a9b4a-5793-49e5-bc5f-ccbd1b2de2af@isocpp.org> X-Original-Sender: david@westcontrol.com X-Original-Authentication-Results: mx.google.com; spf=neutral (google.com: 195.159.176.226 is neither permitted nor denied by best guess record for domain of gclcip-std-proposals@m.gmane.org) smtp.mailfrom=gclcip-std-proposals@m.gmane.org 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:40468 Archived-At: 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 > > 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. .