220 37541 <2ad48eb7-a635-4aaf-9216-7a390791c083@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Nicol Bolas 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:48:50 -0700 (PDT) Lines: 106 Approved: news@gmane.org Message-ID: <2ad48eb7-a635-4aaf-9216-7a390791c083@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> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_13150_1562601011.1522252130851" X-Trace: blaine.gmane.org 1522252010 12386 195.159.176.226 (28 Mar 2018 15:46:50 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 28 Mar 2018 15:46:50 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBY7S53KQKGQEC2I3RXA@isocpp.org Wed Mar 28 17:46:46 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vk0-f72.google.com ([209.85.213.72]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f1DHg-00037J-W6 for gclcip-std-proposals@m.gmane.org; Wed, 28 Mar 2018 17:46:45 +0200 Original-Received: by mail-vk0-f72.google.com with SMTP id w1sf1881419vke.23 for ; Wed, 28 Mar 2018 08:48:52 -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=hVD2tIbaVlfmiYQItRdJi3yyOruKbzeQ+Jxd3ogoiUk=; b=th1VbAWsP2e9eHqQCkIKv0TwJ/nT07Yx2aXgNEF2HTUSJpck6YSHcJiyH+9bdfSq31 DEk6T2jdpT7aZX+owNPasGeW9yeHmSGTNDUGo/jBHUdzkUc2MU8kc5doOZODp70odFD+ XK6HI6opb1r33IpcPDy498/XXBP/YB2eB2itiRtz+qrkMGc14eelbL+KhULNvyNqdaoI 4gTF599w4tnO0UwoCDx7GuS9Us+taRKikFI7Tcx9eIKpMgmfWeWk37H6mh484ZDhVQAX lp0vbHoRyHLyA6MaTt/vzOZSY/n1zIfoYnJBUCFqeB+jYpM5fss8PvHhlOL/QSzwsf0W IFqg== 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=hVD2tIbaVlfmiYQItRdJi3yyOruKbzeQ+Jxd3ogoiUk=; b=l4Pxbyf1ugT2tSQaPcfhwBJ5JVpNKy1Ki1XzuDx3jn2puQ3uVEF+Umh0Y51m1KJZby fxccsnE9YUAIgvHRnFQF1G0q1VolYU6rq5rC+/4BST6SJYO4DgXfTXLpVYRSfMjyX5Ep O585xgHBWKwJWC9tqm5Wm6XpEMWm7sk3w7B+7D+ChgOkHV3wTAPYw44cxNWoW3w0UWW9 iqLhFI0Z1AnShSDC6NBbTm/S3joa0A1h8JIDiq0ZlftzAxRktyeocVPWKaGFjDRURgJl T1F7nGwNbvzudUNOpCQFExOFpa9OdUzgriSIPIqLbptfCvb/0+xDt7nScK6BbYxCgQvz c1Fg== 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=hVD2tIbaVlfmiYQItRdJi3yyOruKbzeQ+Jxd3ogoiUk=; b=UgQieduu1b/K+Q4V59d6J25rN0PIoU+opslWkIgVF7/W3W5DEWObZ4qZoGlo7eh3G4 hRLof+n4wgZgGxgzZuMjWSeZilQSC+Cg6TFXrsQBLx0vKAeDThf/fHraJk6FD3vZ/e6d T0h5EylCv/S4eM9IaKQ/E1qYDpEAYgnGghLPz0MF2Aw7FiTLXeGYzv+xu9SUb6knUqRR y26YF/M0oFZRnqucnM1S0j9ri+pW+1xwxwCnleRloxhfuZtTpXRMA8cgxWbS46gl+TMs AMUTbfUnXF9cTvCzxBVgrw6nXoUKjRWhJ+kNmh4mh/LX0O4ly74CeeQRJiP+ah+38P10 KRfw== X-Gm-Message-State: AElRT7H0T01hZL+ctoe25v4RvHwzjegojId1mx5T56qcGrt6BAElNhhd Y0nOb2eVhk7mztiuxwM3nGQnbw== X-Google-Smtp-Source: AIpwx4+ENToFag5HlsU8jNXDTLSf66wc15SY9nKbBEvyoy4N58Hms6DFAf6JnroFp8nEcSXLiWd4uA== X-Received: by 10.176.96.56 with SMTP id n24mr6671552ual.5.1522252132503; Wed, 28 Mar 2018 08:48:52 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.31.189.204 with SMTP id n195ls569344vkf.14.gmail; Wed, 28 Mar 2018 08:48:51 -0700 (PDT) X-Received: by 10.31.151.87 with SMTP id z84mr6000811vkd.5.1522252131232; Wed, 28 Mar 2018 08:48:51 -0700 (PDT) In-Reply-To: <8eb5c7cd-42ec-46bd-8aee-842ef11b885e@isocpp.org> X-Original-Sender: jmckesson@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:37541 Archived-At: ------=_Part_13150_1562601011.1522252130851 Content-Type: multipart/alternative; boundary="----=_Part_13151_342019493.1522252130851" ------=_Part_13151_342019493.1522252130851 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 scrit= to: >> >> 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 t= o=20 >> continue supporting the old interfaces. Unless you are willing to write= =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 amo= unt=20 >> of floating point math in the containers. >> >> reserve does math on the load factor. insert does comparisons with the= =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 perfor= m=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 using= =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. --=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/2ad48eb7-a635-4aaf-9216-7a390791c083%40isocpp.or= g. ------=_Part_13151_342019493.1522252130851 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


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 Cr= aig ha scritto:
Even if you add new interfaces to deal with the load factor, the internal= s are likely to still need to use floating point math in order to continue = supporting the old interfaces.=C2=A0 Unless you are willing to write your o= wn std::unordered_* containers and replace the ones shipped with libstdc++ = or libc++ with those, you will probably be stuck with some amount of floati= ng point math in the containers.

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

That is incorrect. The implementation is= allowed to store and use internally a fixed point representation of the ma= x load factor and perform math on such value. The only places in which floa= ting point is actually necessary are the interface functions max_load_facto= r() and load_factor().

Oh yes, they= 9;re "allowed" to. But why would they? Most standard library impl= ementations are not generally written under the assumption that using `floa= t` is slow, so given the interface of the type, they probably just store an= d use a `float`. Therefore, to get this benefit, you have to be using an im= plementation that internally used fixed-point or whatever.

--
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/2ad48eb7-a635-4aaf-9216-7a390791c083= %40isocpp.org.
------=_Part_13151_342019493.1522252130851-- ------=_Part_13150_1562601011.1522252130851-- .