220 37556 article Path: news.gmane.org!.POSTED!not-for-mail From: Kevin Fitch Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Remove floating point requirement for unordered (multi) set/map Date: Thu, 29 Mar 2018 06:59:52 -0700 (PDT) Lines: 213 Approved: news@gmane.org Message-ID: 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> <7b2a1e15-f345-4749-ab74-b5a53b5dbed0@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_2735_1257862455.1522331992928" X-Trace: blaine.gmane.org 1522331873 19694 195.159.176.226 (29 Mar 2018 13:57:53 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 29 Mar 2018 13:57:53 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCNZV4UAUMBRBWXC6PKQKGQEXVXDBJI@isocpp.org Thu Mar 29 15:57:49 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 1f1Y3o-00051Y-53 for gclcip-std-proposals@m.gmane.org; Thu, 29 Mar 2018 15:57:48 +0200 Original-Received: by mail-ua0-f200.google.com with SMTP id d12sf3906057ual.9 for ; Thu, 29 Mar 2018 06:59:56 -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=ueNEzA/vWTL+3etT+JfP6rViZ1ELVTABY7h7MzP4+pg=; b=ZAkaHyk0q3QPlVJW/BKkqfiaRZwzlHTrRFv7jbqKpgtdbF472DcgbvTWe6tkm6+/CP nvk5hAjthRD7eEV+wJaGh7usjXsUTiGNvlMacjitg0tljg57GLkPxMraGWo5qs6NhPB7 mNYt/yTokreqXGvFvP6jw95kpNknYMd+SkyeCu32A8uTneYE9KQfRe+djOZCsMYuRrAC mTu2iW4zQU6vXqRvCX5C0PR9n0rfaS+KxKcLQD7jwOYUIzyhUYGU6gZ9U+k44oGeM1Lr SJK6BGHBW4/ILHakJ+cnXT4luL/Xkg7uylW5eHoITtx8ASLZEjfRTSMnrLXd4/tzUCGh 7HSw== 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=ueNEzA/vWTL+3etT+JfP6rViZ1ELVTABY7h7MzP4+pg=; b=g+J20i9jqC+F+eHDLpLQ51sgcrgRuQ9eKReMLGjuK2e8nXRg3w2Vl5vZ39J3E4nQG8 zQMw7IduWCxgA5pg1wLlruBa5gCEJBg6HW0exvzej3YY3gZzTRMpN00uXKdfJpICX9ut IFmWgFtx1e60kp4IYWR1ELfFBNypHwFId5TM3kxiJeURxaiNsC3YELLXakagNxJW4hBu Sr9twAJY+uyZ/g92kle60leK5OLpnrBc1CPYl7ZE40CSO3YqOUbSrEw0L5TXytxoIFvJ 49OBrcgsc4dpgwnWMx+N14aQeLmL256JHsWaYgXk1Yf+0UX7OGeWlmHtdelKGcrWuvve OGvw== 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=ueNEzA/vWTL+3etT+JfP6rViZ1ELVTABY7h7MzP4+pg=; b=Q81X4pqW+DleR1Vebm4Atqr0DeAmwofQjjvDAbY6RhoP0i8/BKF7XzN0rvRXPXcHYb M194VQlbNHY3S6i8n1PMLyeYWvgMB4C5/JAqnfSSqteiBL4TWMRJn/jl3fRUjecfDLj4 hVZxYwekSDPPHHy5cAqqyfi3WeXJlNpFXUhV9uoWDSDxzCqVzMs7MMWOUaVu9GZOUFGy cEJF+tuZMFE8QmwwvLNJs/MDTaLbU5wUud1lfANYSNkYMNvd/A5vvNuZw8ppxmk3DMCP EQLudQqAnDl8HYOaV0ZRVj8xUoazaScKeZeCGzSREA7LhokewogWtcO5LPzZ76daMF4G qrfg== X-Gm-Message-State: AElRT7GsJPMT7QT9fOCJkNh2KADXlRfS9ejtjllOS/joPH/9SAuMmpIV neW0UJ2mSHVGzpB2w9et1vtgNw== X-Google-Smtp-Source: AIpwx4+Yp0IU3571+UliuUcadS6rUR7JL+G26ibDozgxdmViuFO58IXzwZLqaslbzOkxHbAxX5FwUg== X-Received: by 10.31.137.67 with SMTP id l64mr6844609vkd.12.1522331995580; Thu, 29 Mar 2018 06:59:55 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.31.213.194 with SMTP id m185ls3717047vkg.15.gmail; Thu, 29 Mar 2018 06:59:54 -0700 (PDT) X-Received: by 10.31.158.83 with SMTP id h80mr6501352vke.9.1522331993484; Thu, 29 Mar 2018 06:59:53 -0700 (PDT) In-Reply-To: <7b2a1e15-f345-4749-ab74-b5a53b5dbed0@isocpp.org> X-Original-Sender: kfitch42@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:37556 Archived-At: ------=_Part_2735_1257862455.1522331992928 Content-Type: multipart/alternative; boundary="----=_Part_2736_956759062.1522331992929" ------=_Part_2736_956759062.1522331992929 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wednesday, March 28, 2018 at 5:31:48 PM UTC-4, Ben Craig wrote: > > Implementations that are targeted at embedded platforms that are fine wit= h=20 > allocations, fine with exceptions or termination semantics, but not fine= =20 > with floating point. > To clarify, was that statement meant to be a question? Perhaps you meant to= =20 say: Do there exist ... And, I would say, emphatically, there are=20 applications using implementations of the STL targeted at embedded=20 platforms where that is true. Most often I see applications that are fine= =20 with allocations (with a few restrictions), but not fine with exceptions or= =20 floating point. They key is that implementations targeted at embedded=20 platforms need to deal with applications that are (or are not) fine with=20 each of those (and many other things) independently. You can (with a little= =20 effort) use all the features of the STL without using exceptions (e.g.=20 using operator[] instead of "at" to access members of a vector). You can=20 use allocators to deal with restrictions on allocation on the platform...= =20 > > 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 fact= or=20 > methods, you won't get the floating point size hit. > Sure, and something like that is probably going to have to be my short term= =20 solution. I was just hoping to get to a place where I (and other=20 developers) might not have to do that in the future. My point was that the= =20 current standard makes it impossible to create an implementation that can= =20 be used fully while avoiding floating point. I see this at the same level= =20 as having both operator[] and "at" so that the the user/application can=20 decide what features they want to pay for.=20 > > 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 sc= ritto: >>> >>> >>> On Wednesday, March 28, 2018 at 11:42:24 AM UTC-4, Alberto Barbati wrot= e: >>>> >>>> >>>> Il giorno mercoled=C3=AC 28 marzo 2018 17:35:48 UTC+2, Ben Craig ha sc= ritto: >>>>> >>>>> 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 orde= r to=20 >>>>> continue supporting the old interfaces. Unless you are willing to wr= ite=20 >>>>> your own std::unordered_* containers and replace the ones shipped wit= h=20 >>>>> libstdc++ or libc++ with those, you will probably be stuck with some = amount=20 >>>>> of floating point math in the containers. >>>>> >>>>> reserve does math on the load factor. insert does comparisons with= =20 >>>>> the 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 per= form=20 >>>> math on such value. The only places in which floating point is actuall= y=20 >>>> necessary are the interface functions max_load_factor() and load_facto= r(). >>>> >>> >>> Oh yes, they're "allowed" to. But why would they? Most standard library= =20 >>> implementations are not generally written under the assumption that usi= ng=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 embedde= d=20 >> platform *can* do that. Of course, general purpose libraries like libstd= c++=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/fa334b81-aa3e-4542-92cf-42a890677689%40isocpp.or= g. ------=_Part_2736_956759062.1522331992929 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wednesday, March 28, 2018 at 5:31:48 PM UTC-4, = Ben Craig wrote:
Implementations that are targeted at embedded platforms that are fine wi= th allocations, fine with exceptions or termination semantics, but not fine= with floating point.
To clarify, was that statement= meant to be a question? Perhaps you meant to say: Do there exist ... And, = I would say, emphatically, there are applications using implementations of = the STL targeted at embedded platforms where that is true. Most often I see= applications that are fine with allocations (with a few restrictions), but= not fine with exceptions or floating point. They key is that implementatio= ns targeted at embedded platforms need to deal with applications that are (= or are not) fine with each of those (and many other things) independently. = You can (with a little effort) use all the features of the STL without usin= g exceptions (e.g. using operator[] instead of "at" to access mem= bers of a vector). You can use allocators to deal with restrictions on allo= cation on the platform...

Note however that libc++ and lib= stdc++ are both open source.=C2=A0 If you are willing to maintain 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 g= et the floating point size hit.
Sure, and = something like that is probably going to have to be my short term solution.= I was just hoping to get to a place where I (and other developers) might n= ot have to do that in the future. My point was that the current standard ma= kes it impossible to create an implementation that can be used fully while = avoiding floating point. I see this at the same level as having both operat= or[] and "at" so that the the user/application can decide what fe= atures they want to pay for.

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 wrot= e:

Il giorno me= rcoled=C3=AC 28 marzo 2018 17:35:48 UTC+2, Ben Craig ha scritto:
Even if you add new inte= rfaces 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 interfa= ces.=C2=A0 Unless you are willing to write your own std::unordered_* contai= ners 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 conta= iners.

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 max load factor and perform = math on such value. The only places in which floating point is actually nec= essary are the interface functions max_load_factor() and load_factor().
=

Oh yes, they're "allowed" t= o. But why would they? Most standard library implementations are not genera= lly written under the assumption that using `float` is slow, so given the i= nterface of the type, they probably just store and use a `float`. Therefore= , to get this benefit, you have to be using an implementation that internal= ly used fixed-point or whatever.

QOI. = My point is that an implementation specifically targeted to embedded platfo= rm *can* do that. Of course, general purpose libraries like libstdc++ and l= ibc++ probably won't do that.
<= /blockquote>

--
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/fa334b81-aa3e-4542-92cf-42a890677689= %40isocpp.org.
------=_Part_2736_956759062.1522331992929-- ------=_Part_2735_1257862455.1522331992928-- .