220 37554 <7b2a1e15-f345-4749-ab74-b5a53b5dbed0@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 14:31:48 -0700 (PDT) Lines: 150 Approved: news@gmane.org Message-ID: <7b2a1e15-f345-4749-ab74-b5a53b5dbed0@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> <1df72d61-2659-4864-9a6d-f8ea8fe52792@isocpp.org> <8eb5c7cd-42ec-46bd-8aee-842ef11b885e@isocpp.org> <2ad48eb7-a635-4aaf-9216-7a390791c083@isocpp.org> <8698cc1b-bce1-4c23-bf81-2cab986afe5a@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_593_1954642471.1522272708442" X-Trace: blaine.gmane.org 1522272589 1552 195.159.176.226 (28 Mar 2018 21:29:49 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 28 Mar 2018 21:29:49 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDCM7T7A5UMRBRMT6DKQKGQEFDP5J4Q@isocpp.org Wed Mar 28 23:29:44 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ua0-f200.google.com ([209.85.217.200]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f1Idb-0000IC-Hx for gclcip-std-proposals@m.gmane.org; Wed, 28 Mar 2018 23:29:43 +0200 Original-Received: by mail-ua0-f200.google.com with SMTP id o13sf2604490uak.5 for ; Wed, 28 Mar 2018 14:31: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=wFfaK7jB7SsROsXWg8XLjWLyr/eGpLrxYoH9HNzH+Uc=; b=NHx1Nqhr04HGnXkgR+HkMCyskvnpm5Ac0VuBO/nhxpanzQjrvZOS5aMHbSss0dLXCO fPOoZb7xnTLYCmD61dadNBrsLKKyvUmOiqrXiW2DoNlumTdEBEzIdANKrCTsD02yP77M xdEtogWK4f0hb8HsL9Rz3vBo8vE7VCN90Eal9L9jqB3fHeZ7RzeOSReiFkUbpaaRK9Hu HiKpJp3AKyJfMOxL3ciXdCzmfvpk8hfOGCVZ50Betl3UY2GUGDEG2+u5AmtD02dfBQxv 9mUFDoG5qkVj1UvzOwxwhleXcJKJ7dEquNj2O0zUUf2W6JM1pD5Rpu4yL/MbZBA1vvcr Qapw== 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=wFfaK7jB7SsROsXWg8XLjWLyr/eGpLrxYoH9HNzH+Uc=; b=UFTB27Mkb742rrKjwpiIb9Q3RTm1FMm5+dSSUQnhl60rVOGLYeflMEZRgD21DEqysL 7f655w582LDEMGEldvtBc+PrKkbSE3bW3OwSQQX7TYHn638rJuo8FRGHtd0ThNC5Q3BU GajbcIEQHQR1d3qIzs4ZHZF/ysEZXjnq3N0r8tS2ir3SC8VXNO7jzPfqPR0b/G0dwj9q dNIIznsJkQl+G6PafzszstEo2edgW4UC7/9KoNB2qqS6S0CXKgCLTcDWhosL2nVuXOeE JFcq76JBfHG3zG6ULXeVLrbZU7qXefDUFnIB/Lia/PuNPpNCO7+LkR8NR0bh9/o3pCXc 3AjA== 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=wFfaK7jB7SsROsXWg8XLjWLyr/eGpLrxYoH9HNzH+Uc=; b=Wub5xxvvTMjcXMTFuOhfAZr5ijHgnWUf6AazeYYkp2hlBonEZQbcPuV1bKN+fPAg9b 8dR0lhbadKkEFOKgd+LQztpz8Dr3N2Es1HnqWDt7fmgSEAWQSEo5/VBL2yWgu0BbLoEn KhA6rQbchj5nhQ/8L54bP8x0qSyPOUEdJKjCfmOdz9qzn00C5Hr+qz4ks/2cCyWDNDb8 Hd9HHEs5Xq0cQQEX0Tl1dC1XyRBhVu472S/Jn9b999RSVvzypkzhzG5nznCS24ZUGu4a PAtSbcTpZCi3si6k9zPoWlvhvyGPkSDTLNYvNORdNTrC1hwy6DXhtiqqnBK+0fArWJ+6 WE2Q== X-Gm-Message-State: AElRT7FPfrod6LBdP52pQm4087xHhd+8q2WvT/dojDGUTHAV1TZseLit /656TriUkwz1XDecl10tgClEIg== X-Google-Smtp-Source: AG47ELuyESsljO89yLQpziXOm8h0J9mSxwqO6mQVUhCLBcU17b4Tu9Qc5k5fLptlA9nRFAhXvrDWjw== X-Received: by 10.31.179.77 with SMTP id c74mr17137344vkf.59.1522272710674; Wed, 28 Mar 2018 14:31:50 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.31.168.77 with SMTP id r74ls2903837vke.17.gmail; Wed, 28 Mar 2018 14:31:49 -0700 (PDT) X-Received: by 10.31.148.135 with SMTP id w129mr2294186vkd.14.1522272708965; Wed, 28 Mar 2018 14:31:48 -0700 (PDT) In-Reply-To: <8698cc1b-bce1-4c23-bf81-2cab986afe5a@isocpp.org> 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:37554 Archived-At: ------=_Part_593_1954642471.1522272708442 Content-Type: multipart/alternative; boundary="----=_Part_594_722857617.1522272708442" ------=_Part_594_722857617.1522272708442 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Implementations that are targeted at embedded platforms that are fine with= =20 allocations, fine with exceptions or termination semantics, but not fine=20 with floating point. Note however that libc++ and libstdc++ are both open source. If you are=20 willing to maintain your own toolchain, you can fork them. If you modify= =20 the internals to not use floating point, and you never call the load factor= =20 methods, you won't get the floating point size hit. On Wednesday, March 28, 2018 at 10:53:01 AM UTC-5, Alberto Barbati wrote: > > Il giorno mercoled=C3=AC 28 marzo 2018 17:48:50 UTC+2, Nicol Bolas ha scr= itto: >> >> >> On Wednesday, March 28, 2018 at 11:42:24 AM UTC-4, Alberto Barbati wrote= : >>> >>> >>> Il giorno mercoled=C3=AC 28 marzo 2018 17:35:48 UTC+2, Ben Craig ha scr= itto: >>>> >>>> Even if you add new interfaces to deal with the load factor, the=20 >>>> internals are likely to still need to use floating point math in order= to=20 >>>> continue supporting the old interfaces. Unless you are willing to wri= te=20 >>>> your own std::unordered_* containers and replace the ones shipped with= =20 >>>> libstdc++ or libc++ with those, you will probably be stuck with some a= mount=20 >>>> of floating point math in the containers. >>>> >>>> reserve does math on the load factor. insert does comparisons with th= e=20 >>>> load factor. >>>> >>> >>> That is incorrect. The implementation is allowed to store and use=20 >>> internally a fixed point representation of the max load factor and perf= orm=20 >>> math on such value. The only places in which floating point is actually= =20 >>> necessary are the interface functions max_load_factor() and load_factor= (). >>> >> >> Oh yes, they're "allowed" to. But why would they? Most standard library= =20 >> implementations are not generally written under the assumption that usin= g=20 >> `float` is slow, so given the interface of the type, they probably just= =20 >> store and use a `float`. Therefore, to get this benefit, you have to be= =20 >> using an implementation that internally used fixed-point or whatever. >> > > QOI. My point is that an implementation specifically targeted to embedded= =20 > platform *can* do that. Of course, general purpose libraries like libstdc= ++=20 > and libc++ probably won't do that. > --=20 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 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/7b2a1e15-f345-4749-ab74-b5a53b5dbed0%40isocpp.or= g. ------=_Part_594_722857617.1522272708442 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Implementations that are targeted at embedded platforms th= at are fine with allocations, fine with exceptions or termination semantics= , but not fine with floating point.

Note however that li= bc++ and libstdc++ are both open source.=C2=A0 If you are willing to mainta= in your own toolchain, you can fork them.=C2=A0 If you modify the internals= to not use floating point, and you never call the load factor methods, you= won't get the floating point size hit.

On Wednesday, March 28, = 2018 at 10:53:01 AM UTC-5, Alberto Barbati wrote:
Il giorno mercoled=C3=AC 28 marzo 2018 = 17:48:50 UTC+2, Nicol Bolas ha scritto:

On Wednesday, March 28, 2018 at 11:42:24 AM UTC-4,= Alberto Barbati wrote:

Il giorno mercoled=C3=AC 28 marzo 2018 17:35:48 UTC+2, Ben Craig h= a scritto:
Eve= n 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 suppo= rting the old interfaces.=C2=A0 Unless you are willing to write your own st= d::unordered_* containers and replace the ones shipped with libstdc++ or li= bc++ with those, you will probably be stuck with some amount of floating po= int math in the containers.

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

That is incorrect. The implementation is allo= wed to store and use internally a fixed point representation of the max loa= d factor and perform math on such value. The only places in which floating = point is actually necessary are the interface functions max_load_factor() a= nd load_factor().

Oh yes, they're = "allowed" to. But why would they? Most standard library implement= ations are not generally written under the assumption that using `float` is= slow, so given the interface of the type, they probably just store and use= a `float`. Therefore, to get this benefit, you have to be using an impleme= ntation that internally used fixed-point or whatever.

QOI. My point is that an implementation specifically target= ed to embedded platform *can* do that. Of course, general purpose libraries= like libstdc++ and libc++ probably won't do that.

--
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/7b2a1e15-f345-4749-ab74-b5a53b5dbed0= %40isocpp.org.
------=_Part_594_722857617.1522272708442-- ------=_Part_593_1954642471.1522272708442-- .