220 37536 <1df72d61-2659-4864-9a6d-f8ea8fe52792@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Ben Craig Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Remove floating point requirement for unordered (multi) set/map Date: Wed, 28 Mar 2018 08:35:48 -0700 (PDT) Lines: 240 Approved: news@gmane.org Message-ID: <1df72d61-2659-4864-9a6d-f8ea8fe52792@isocpp.org> References: <4c98e549-8f0c-42e5-a054-0234f7cf1e46@isocpp.org> <9d4a8ea3-9e7d-4851-8b28-5cd67779081a@isocpp.org> <1356e140-2985-4fe7-b9ee-70e40738d1cf@isocpp.org> <7b853bcd-47f5-4c2c-841b-13e30472e14c@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_22445_356550585.1522251348630" X-Trace: blaine.gmane.org 1522251229 22467 195.159.176.226 (28 Mar 2018 15:33:49 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 28 Mar 2018 15:33:49 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDCM7T7A5UMRBVPM53KQKGQEUZPC7EA@isocpp.org Wed Mar 28 17:33:45 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vk0-f70.google.com ([209.85.213.70]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f1D55-0005gg-EI for gclcip-std-proposals@m.gmane.org; Wed, 28 Mar 2018 17:33:43 +0200 Original-Received: by mail-vk0-f70.google.com with SMTP id u84sf1911453vke.13 for ; Wed, 28 Mar 2018 08:35:51 -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=/7ak/5e4GCcgVi1wf6ybD2BI4R1MhhGcYXSUZwEWBRs=; b=JqirMVe0Dhumbi0kyGbhNmn/3qRgU8uflslBeyuf5Xx28s8oLA12E4pXXDnSF0u7AP BRb0lgO9rM7eRFWc+zrsWD2j5CqGU86mht90sVHpO6/V6euUVA/IOwKHLYWfkswysmKL pNRLDfDbSOGlXU+38Py4vT+wYxGWCyCzZlv9H7wOf7INu5IsO2v59qLLQiUbH/oqFRJp 3nsTVEjSzfIvgPvb3gw/cJbccQe4WzAM7fHf++gGZPVZiRoJb+YZZxckGDP/agsZOJyy jbPkwS5SjkzNyUSsehrnR+gbErXonHxKoLrTsey53BsYsf2jEI7afkcucc5os5nG7YHu ZQxA== 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=/7ak/5e4GCcgVi1wf6ybD2BI4R1MhhGcYXSUZwEWBRs=; b=HgWiLOxLhNRtoCRggTu4SR//7xTSSgkhjnfeSkZ+lcNYIHOChHwN4mRG5PC4fRJqJi pF0a1Yy97WsX+B8LUa/f8rPKqSZPHrMHM41+Jrgw/JjtmVxiVdAdGviJTspJA7QxzpbE iORNBnW5FyhZ8dmm7QADuz+gEfmvpWtWrJnNwtEtB3Gqn9tITp5OPAYG/u+61srI1lBn YdZEkruv8Varo4xDzTl9NMC/6asJ3u3amoklHcu/ilWOVZ5h95upILawBQ4TRQkEcRO0 xpJV0pdlfhnE+q5dcALmQTdmQc+4Ore77pp+u3wOELxF+Mt40z3GKYC0kJ5U5E8kYimc IJyw== 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=/7ak/5e4GCcgVi1wf6ybD2BI4R1MhhGcYXSUZwEWBRs=; b=FcCmz2wlyAF1M5pbNJ2XlBfiub9xJsLUnRWqTbMKf7gz9CaMRibmn+AjW1I7+wlTGc RbNo+fL+bstCZelMyjPscqKAfMMMl6Sk8hS2Zk4Cg0GmiCtj+3pSkTzzMgTq4+I7/j5F FhjAOvs8CxUcjW1eKNnCaogErhSGV7be5OQdNKWDE2gVVeyhGhI39V0xOMqytZUdZOSP ZvLDWp+jj/HcHy0cV8ZSFM7Sa4tBFmAXrYjWq6GhJq73NpFe1wJ0r+/gTyp1V4yAUw9n qnRYAEEWCis5NyBPioV82+ISIsKq+yXdHG37kMaqFt2W7nXrwblHIt60OvSiM0rtVSPw ePzA== X-Gm-Message-State: AElRT7ExYSGz1wEW3+pfTvWmHvnkuWHP5Z/EdeNxjh45t2MIxp81jqBj pPL2sQfdiaBdJgMDKG/Pc3Uqjw== X-Google-Smtp-Source: AG47ELskumdqvkh5paPDwJIeMDr6ahwkD1Tn0p2HovlgjnJGcqtdocWtw+ZnWL1DMzXiQTzfLBrh3g== X-Received: by 10.31.16.23 with SMTP id g23mr21148495vki.103.1522251350657; Wed, 28 Mar 2018 08:35:50 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.31.159.193 with SMTP id i184ls2601199vke.18.gmail; Wed, 28 Mar 2018 08:35:49 -0700 (PDT) X-Received: by 10.31.162.10 with SMTP id l10mr2232775vke.12.1522251349047; Wed, 28 Mar 2018 08:35:49 -0700 (PDT) In-Reply-To: X-Original-Sender: ben.craig@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:37536 Archived-At: ------=_Part_22445_356550585.1522251348630 Content-Type: multipart/alternative; boundary="----=_Part_22446_42649931.1522251348630" ------=_Part_22446_42649931.1522251348630 Content-Type: text/plain; charset="UTF-8" Even if you add new interfaces to deal with the load factor, the internals are likely to still need to use floating point math in order to continue supporting the old interfaces. Unless you are willing to write your own std::unordered_* containers and replace the ones shipped with libstdc++ or libc++ with those, you will probably be stuck with some amount of floating point math in the containers. reserve does math on the load factor. insert does comparisons with the load factor. On Wednesday, March 28, 2018 at 10:16:32 AM UTC-5, Kevin Fitch wrote: > > > > On Wednesday, March 28, 2018 at 10:31:46 AM UTC-4, Nicol Bolas wrote: >> >> On Wednesday, March 28, 2018 at 9:40:15 AM UTC-4, Kevin Fitch wrote: >>> >>> Sorry for replying to myself, but I wanted to clarify a few things. >>> First, I think one of the greatest strengths of C++ is the philosophy of >>> not making you pay for features you don't want/need. >>> >> >> But you have to temper that with the question: what is a "feature"? >> > > Yes, the word feature can be a bit nebulous. But looking at the landscape > of computers chips and operating systems out there (i.e. the things the > compiler generated code interacts with), there are many things that would > count as "features": floating-point, MMU, SIMD/vector, multi-threading... > Some of these are more relevant to C++ than others. C++ has been designed > over the years to be able to work just find on both 8-bit micros running > bare metal as well as massive mutli-core servers running "real" OSs. > > >> A particular class or function from the standard library could be >> considered a distinct "feature". Indeed, freestanding implementations are >> not required to implement all parts of the standard library. >> > > What I am concerned with is that os/cpu features that should be > independent are being bundles into a single standard library feature that > means I being pushed away from using the standard library. > > But I have a hard time seeing fundamental types as distinct "features". >> They're called "fundamental" for a reason. I don't see a good reason why >> the standards committee needs to design interfaces on the assumption that >> even *seeing* the keyword `float` constitutes a major disruption to a >> programmer. >> > > I do see a good reason. On many platforms, using any floating point is a > major step change that would disrupt the development process. Many projects > I have worked on had a blanket rule against using floating point. The ones > I have worked on that did not have such a rule were ones where floating > point was central to task being accomplished. I don't think you can look > at both the history and the current state of the computer chip landscape > and not notice that while EVERY CPU has integer support, but there is a > significant subset that does not have floating-point support. > > >> That doesn't mean that they should randomly insert `float` for no good >> reason. But it also doesn't mean that they need to use inconvenient types >> (like a `std::ratio` or whatever) just to avoid using it in interfaces >> where `float` would otherwise be quite natural. >> > > I am not saying that we need to remove the 'float' functions, but I want > to be able to fully use an unordered container without calling them, so > that a decent compiler will elide them and avoid the costs that I don't > want to pay. > > >> >> While there are legitimate cases for arguments along the lines of "a >>> conforming implementation could..." those need to be cognizant of reality. >>> In particular the number of conforming implementations is MUCH smaller than >>> the number of applications using those conforming implementations. Also, >>> the kinds of restrictions I am concerned with are more a function of the >>> application than the platform. Some users of a platform without floating >>> point hardware (e.g. Arduino) might see software floating point as a huge >>> advantage (in terms of things like ease of development), while others using >>> the same chip (e.g. the atmega 328p) might see software floating point as a >>> nonstarter due to things like code size and runtime. >>> >> >> So, the code size and runtime costs of `float` are too much for you, but >> the memory and runtime costs of `unordered_set` are fine? >> > > In a word, YES. I did not post here out of idle speculation. I ran into > exactly this case. Embedded systems are not a simple binary distinction, it > is not even something that is a simple 1 dimensional spectrum. Each system > has its own set of requirements that lead to restrictions that can > surprising. > > >> >>> It should be the goal of the standard to encourage implementations that >>> can gracefully scale in multiple dimensions (required features, code size , >>> memory usage...) to fit the needs of any given application. Adding >>> non-floating-point methods for dealing with load factor would allow >>> conforming implementations to be written such that applications that don't >>> want to floating point, don't have to use floating point. >>> >> >> >> > -- 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/1df72d61-2659-4864-9a6d-f8ea8fe52792%40isocpp.org. ------=_Part_22446_42649931.1522251348630 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Even if you add new interfaces to deal with the load = factor, the internals are likely to still need to use floating point math i= n order to continue supporting the old interfaces.=C2=A0 Unless you are wil= ling to write your own std::unordered_* containers and replace the ones shi= pped with libstdc++ or libc++ with those, you will probably be stuck with s= ome amount of floating point math in the containers.

reserve does math on the load factor.=C2=A0 insert does comparisons with= the load factor.

On Wednesday, March 28, 2018 at 10:16:32 AM UTC-5,= Kevin Fitch wrote:


On Wednesday, March 28, 2018 at 10:31:46 AM UTC-4, Nicol Bola= s wrote:
On Wednesd= ay, March 28, 2018 at 9:40:15 AM UTC-4, Kevin Fitch wrote:
Sorry for replying to myself, but I= wanted to clarify a few things. First, I think one of the greatest strengt= hs of C++ is the philosophy of not making you pay for features you don'= t want/need.

But you have to temper that with th= e question: what is a "feature"?
Yes, the word feature can be a bit nebulous.=C2=A0 But looking at the land= scape of computers chips and operating systems out there (i.e. the things t= he compiler generated code interacts with), there are many things that woul= d count as "features": floating-point, MMU, SIMD/vector, multi-th= reading... Some of these are more relevant to C++ than others. C++ has been= designed over the years to be able to work just find on both 8-bit micros = running bare metal as well as massive mutli-core servers running "real= " OSs.
=C2=A0
A particular class or function from the standard = library could be considered a distinct "feature". Indeed, freesta= nding implementations are not required to implement all parts of the standa= rd library.

What I am concerned with i= s that os/cpu features that should be independent are being bundles into a = single standard library feature that means I being pushed away from using t= he standard library.

But I have a hard time seeing fundamental types as d= istinct "features". They're called "fundamental" fo= r a reason. I don't see a good reason why the standards committee needs= to design interfaces on the assumption that even seeing the keyword= `float` constitutes a major disruption to a programmer.

I do see a good reason. On many platforms, using any floatin= g point is a major step change that would disrupt the development process. = Many projects I have worked on had a blanket rule against using floating po= int. The ones I have worked on that did not have such a rule were ones wher= e floating point was central to task being accomplished.=C2=A0 I don't = think you can look at both the history and the current state of the compute= r chip landscape and not notice that while EVERY CPU has integer support, b= ut there is a significant subset that does not have floating-point support.=
=C2=A0
That doesn't mean that they should randomly insert `float= ` for no good reason. But it also doesn't mean that they need to use in= convenient types (like a `std::ratio` or whatever) just to avoid using it i= n interfaces where `float` would otherwise be quite natural.

I am not saying that we need to remove the 'flo= at' functions, but I want to be able to fully use an unordered container without calling=20 them, so that a decent compiler will elide them and avoid the costs that I don't want to pay.
=C2=A0

While there are legitimate cases for arguments along t= he lines of "a conforming implementation could..." those need to = be cognizant of reality. In particular the number of conforming implementat= ions is MUCH smaller than the number of applications using those conforming= implementations. Also, the kinds of restrictions I am concerned with are m= ore a function of the application than the platform. Some users of a platfo= rm without floating point hardware (e.g. Arduino) might see software floati= ng point as a huge advantage (in terms of things like ease of development),= while others using the same chip (e.g. the atmega 328p) might see software= floating point as a nonstarter due to things like code size and runtime.

So, the code size and runtime costs of `float` ar= e too much for you, but the memory and runtime costs of `unordered_set` are= fine?

In a word, YES. I did not post = here out of idle speculation. I ran into exactly this case. Embedded system= s are not a simple binary distinction, it is not even something that is a s= imple 1 dimensional spectrum. Each system has its own set of requirements t= hat lead to restrictions that can surprising.

=C2=A0
It should be the goal of the standa= rd to encourage implementations that can gracefully scale in multiple dimen= sions (required features, code size , memory usage...) to fit the needs of = any given application. Adding non-floating-point methods for dealing with l= oad factor would allow conforming implementations to be written such that a= pplications that don't want to floating point, don't have to use fl= oating point.

=C2=A0

--
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/1df72d61-2659-4864-9a6d-f8ea8fe52792= %40isocpp.org.
------=_Part_22446_42649931.1522251348630-- ------=_Part_22445_356550585.1522251348630-- .