220 37543 <8698cc1b-bce1-4c23-bf81-2cab986afe5a@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Alberto Barbati 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:53:01 -0700 (PDT) Lines: 124 Approved: news@gmane.org Message-ID: <8698cc1b-bce1-4c23-bf81-2cab986afe5a@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> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_23046_1912591152.1522252381663" X-Trace: blaine.gmane.org 1522252260 30536 195.159.176.226 (28 Mar 2018 15:51:00 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 28 Mar 2018 15:51:00 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCPY5DV6RIMBBXXU53KQKGQECEY2IGY@isocpp.org Wed Mar 28 17:50:56 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ua0-f197.google.com ([209.85.217.197]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f1DLk-0007oO-6x for gclcip-std-proposals@m.gmane.org; Wed, 28 Mar 2018 17:50:56 +0200 Original-Received: by mail-ua0-f197.google.com with SMTP id z27sf1855136uae.23 for ; Wed, 28 Mar 2018 08:53:04 -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=crJScYP2LnRylykSUZq0hAj6ezcqXdxrYHuCPjDtY3E=; b=0NNo3P50wGkP4sS6hQmAdMHAt1BG9xy7ZXOX17iTi2tmiQrEpc3OEK4umKKvBiOcmf D5+VvaMS9NNLJrLYwAoD52fh0FPHKwstTqvbmRJRvpXzCAUFb/F8huEYZJtHZJkjCNCs DiL9Q/T4xelQu0bJ+3HDHeA4tkfpWKNI0/9odA/pAmo42whpbMqL1TinyIwngAwK78+/ q/V2MFafVJdEDzqv+DKCQp88i2dJuvNaARFPh56CqYI+lm+sMjJhU/FaGVp0N0u/52IT Ih9Em1uK2XAmcSKeHsMn+dzm6Qw6vkw/AAB7ymLEyXZA55RRl0Z04oZNwXOjgwnZy+M5 vGZg== 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=crJScYP2LnRylykSUZq0hAj6ezcqXdxrYHuCPjDtY3E=; b=MOrUwrLMI2rNN7C2Sv78nzvEWPuEnTHrDEgD1O0/OW4WY8HqFqF21XJ9YLYSLOWlbx 4S6zR9JgG4ZZpV9MWfarzV0hkkiopDLNkTCnfFvfqWKGmp8qanGWmGLaIM0s524OgyK9 WEVi/BKuopTEdtDoSFb7RQbicQzUHsEhEAzTtmWIi3ODM2nfXRIx2Gz9wg9HW/o21Qcp 9VEFAfsFVk1kmXGGVpUtW2EbixOCi/mvQxTyR/zwnQ9KydOyCE7EYAcDA2segfjb4+Ff bYHH7eLyYKlNbk3bwaHx0C7eZPh20fOocJF/NShMjQrT706bxyALJUHA5Vvwmcd5COMj 7B+Q== 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=crJScYP2LnRylykSUZq0hAj6ezcqXdxrYHuCPjDtY3E=; b=jDnoiQRsM+QDFHF59czNu91LEEmilU0cQgGNg6moIx+37Yb9+h91ORYWoBpB/VvaJG BsQGhPvfcIFKKBeHfICzZw2QCGbbQIBU0ACSNWYMI2CBSKoHO6RUHlJlJPTj3mScVFzH 821ct9ZpWwTWil9AYYeV8i/kzWiwlAlJUUlR9w1iES+bnHzIJKijlH5uauZ50lQjhHXm ccvjIt620JrIfQ+2l8rBk3xbKMwJphrR/xrSqr7g6GtW39qL7RoKXcuTSbBvURSb9iEo tSKglCyVXjmwodvQokuL5n0RcDjwXNs74Ikd8uNWtIgjsXKU9Wb2tdQQ0y+Vpn3w635+ w+8A== X-Gm-Message-State: AElRT7HShVPd8vOSbJ4jj2lxmtuED3GYr+4g5VCmJuN1ULjlxKPeSHiT 2JUNCSrBMEIy1SCfM4bVIN64/g== X-Google-Smtp-Source: AIpwx4/vLjkzBNahc0U98yPOT+fqXAdN7O3nVNFetLUUXlhhk74bMdDeEE1GvWQWPJO/bduLwxtljg== X-Received: by 10.176.26.154 with SMTP id j26mr4402438uai.44.1522252383537; Wed, 28 Mar 2018 08:53:03 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.31.50.79 with SMTP id y76ls2212105vky.7.gmail; Wed, 28 Mar 2018 08:53:02 -0700 (PDT) X-Received: by 10.31.193.140 with SMTP id r134mr6019168vkf.6.1522252382097; Wed, 28 Mar 2018 08:53:02 -0700 (PDT) In-Reply-To: <2ad48eb7-a635-4aaf-9216-7a390791c083@isocpp.org> X-Original-Sender: AlbertoBarbati@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:37543 Archived-At: ------=_Part_23046_1912591152.1522252381663 Content-Type: multipart/alternative; boundary="----=_Part_23047_1007668085.1522252381663" ------=_Part_23047_1007668085.1522252381663 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Il giorno mercoled=C3=AC 28 marzo 2018 17:48:50 UTC+2, Nicol Bolas ha scrit= to: > > > 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 scri= tto: >>> >>> 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 writ= e=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 am= ount=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 perfo= rm=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. > 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/8698cc1b-bce1-4c23-bf81-2cab986afe5a%40isocpp.or= g. ------=_Part_23047_1007668085.1522252381663 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Il giorno mercoled=C3=AC 28 marzo 2018 17:48:50 UTC+2, Nic= ol Bolas ha scritto:

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

Il = giorno mercoled=C3=AC 28 marzo 2018 17:35:48 UTC+2, Ben Craig ha scritto:
Even if you add= new interfaces to deal with the load factor, the internals are likely to s= till need to use floating point math in order to continue supporting the ol= d interfaces.=C2=A0 Unless you are willing to write your own std::unordered= _* containers and replace the ones shipped with libstdc++ or libc++ with th= ose, you will probably be stuck with some amount of floating point math in = the containers.

reserve does math on the load fact= or.=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 max load factor and= perform math on such value. The only places in which floating point is act= ually necessary are the interface functions max_load_factor() and load_fact= or().

Oh yes, they're "allowe= d" to. But why would they? Most standard library implementations are n= ot generally written under the assumption that using `float` is slow, so gi= ven the interface of the type, they probably just store and use a `float`. = Therefore, to get this benefit, you have to be using an implementation that= internally used fixed-point or whatever.
=
QOI. My point is that an implementation specifically targeted to embedd= ed platform *can* do that. Of course, general purpose libraries like libstd= c++ 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/8698cc1b-bce1-4c23-bf81-2cab986afe5a= %40isocpp.org.
------=_Part_23047_1007668085.1522252381663-- ------=_Part_23046_1912591152.1522252381663-- .