220 37502 article Path: news.gmane.org!.POSTED!not-for-mail From: =?UTF-8?B?R2HFoXBlciBBxb5tYW4=?= Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Remove floating point requirement for unordered (multi) set/map Date: Tue, 27 Mar 2018 20:55:59 +0100 Lines: 179 Approved: news@gmane.org Message-ID: References: <4c98e549-8f0c-42e5-a054-0234f7cf1e46@isocpp.org> <3dcffdf5-ea1a-41bf-87ab-1c1ddae52404@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="089e08268ddcc1917a05686a4840" X-Trace: blaine.gmane.org 1522180459 3865 195.159.176.226 (27 Mar 2018 19:54:19 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 27 Mar 2018 19:54:19 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDRYVJ6TVYBRBZOD5LKQKGQENSSJM3Y@isocpp.org Tue Mar 27 21:54:15 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pg0-f71.google.com ([74.125.83.71]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f0uff-0000sa-4V for gclcip-std-proposals@m.gmane.org; Tue, 27 Mar 2018 21:54:15 +0200 Original-Received: by mail-pg0-f71.google.com with SMTP id o1sf34474pga.7 for ; Tue, 27 Mar 2018 12:56:22 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1522180582; cv=pass; d=google.com; s=arc-20160816; b=fQ3b7X07aA6BNcFtvmmPfW0cZ+TYGN4kggSHpVuPzK82kHTdft99bOK+B9n/y448Rz vUP0vbQ0Zy+myUbsMjoOrsvEwxFtI6cc6wyapYoxXTxnJk9Q1JbMefIkYs6D6pwHOv3W c45+yX5cfGWnhiE9DxdZRlc+0j/BVBevDuI0v9jWAPlurDupw2s53FoOo2nCHFPCqEFD rIeED+E/vIDwdrJft8Gl/HAP9vgz1kr1dilidokm3dXaePPBj+2N51bA0sPNPaMoOpyW HPTtriUKulEbCCsPMsguiR51Cql92xH0yfzVyZzF2Knar+aGh1pc3psoBPpnJ1LF6bOS +oFg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:to:subject:message-id:date :from:references:in-reply-to:mime-version:arc-authentication-results :arc-message-signature:dkim-signature:arc-authentication-results; bh=0AIoiOUsaHqhq8OdbEIW391vcI3GLiT2LYrBFkxon+c=; b=mD9idsMf8wdqZTTuA7G4i7+sHpu0dA/AgkZSv8zMvIqxG4INHEbBe3K1AYxmna7gvd qOpqOLZI+xDLUm55AgZ8uzfphW4HoA2pV4GxeGMklcRaRdHwXMPQ3+R5YJuNBxkYuQXb rYfdXt/LydwkGNBme4Ax0c++DssMhAGw0z+7lQaph2noC102YuUUYlY6L5xDzDvEOiUs xC8SWjo2O5eUUdGsskBlGm6VEU58EPusk6ojNJ/rDsgCZiBnUYuo9LHwmKu33I8VgVyR 1uRpDCFKi03TnQ6PHQwq7YAP/mxh7RHMj6DSiAexYHQvTWhTGwiDxiMQ/0H2h19SJOiJ GG+w== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Epf5EDA5; spf=pass (google.com: domain of gasper.azman@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=gasper.azman@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=0AIoiOUsaHqhq8OdbEIW391vcI3GLiT2LYrBFkxon+c=; b=ZUFhX400+rF72rOxkaJtfUntunv2iKKUt3W3o5nQqQGzh5srfAlYofOf/q+OIh4eZI qt1B1HIx87schBbRR706R9cqLm6BPsuocJEYdvAtTFQlKWY9PnYICyb5bbniu8OXSQNT 6xSy4ETefervWYtF6f/8PA6hcUW3bstF4dt9Bo4rBE23SnFYHmZQ3lL89k67eI0CURAx 1/lEBlUkWjXlk2WS6ox2S8tQ9a7/iBiyt8C03e4Z4wO6I75xilD6PVNVch1BLy//TPJT 83/4V5iLiBKFIZmhqm0ik2L/C4fsh5J6rOM3yjZ4lMMSh3kRVJ/l9Ed9ePDhjzIs6AK8 pxLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=0AIoiOUsaHqhq8OdbEIW391vcI3GLiT2LYrBFkxon+c=; b=ohZKqVz+bUIemcfMhIGTe+bg2zg9WUqVBqCP6qHMFPGUR88ertLY2p/bPBFHmpS3sX cLT1pKyT72T/5BXBfcEYaG7AMVu4FGaysbUm3cJDfKotamyF4rCmfg6/o/ctdDAy5zIe W1Z1Uw6bp2HcEZkid9LuxDXB/ciGbED9Le05Dg4a1CobbHDF5VhHVKq78qeK0YqWcM+D mTgfuR9NDsxGeMGvgxdR7Gyj/grAyxrLEg4bBYQ/r50TO8sPN8KYRZZ/Ul2KgrgiYHlD 08bfmUFh96FRPNSSmu1bl97tfluKjZohPEN2vvlyJ0lWlBBfgTdwFXvSsEhACXHcigGc g5UA== X-Gm-Message-State: AElRT7Euo33oNF2W0aU5fNuvrmLwsd3IKNh6w1sxN1Or7J2mlDH19kAl /ymDBWQaRGjUIJyiBIISwOAXjA== X-Google-Smtp-Source: AG47ELuahklUw0u0gfnz4lEhUHENxVOwJmLx8ZOGA4svAvyGlkHYoJtDphGjRghfq8bUF0AQe8XWdw== X-Received: by 2002:a17:902:6b0c:: with SMTP id o12-v6mr15439258plk.60.1522180582297; Tue, 27 Mar 2018 12:56:22 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.101.93.77 with SMTP id e13ls419845pgt.5.gmail; Tue, 27 Mar 2018 12:56:20 -0700 (PDT) X-Received: by 10.101.74.69 with SMTP id a5mr486041pgu.32.1522180580739; Tue, 27 Mar 2018 12:56:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522180580; cv=none; d=google.com; s=arc-20160816; b=LQRCOA+2SK7TolUEyWUcB+Vti3rv9XLmAsZ7FBkaDQOd9QTN0N5e/xYVfsAQDx5iq9 PvUMQ7pdQFd6gFj9zvNJHD0bxa3Nq23afnX1EHcurwVuNn//HQm19M4UE+IiXsTFp2KS Ye2XH/KOVPq2CXnz4mqI3garWo3d7A3DqA4Wt9VCaiFC3BBb9tBx/xaBPi0CWX7el3bd a2HLqkzw0o7sa6O5xSYIUnJvr5A2vKIuHNXeWvsk/HCmKbe4VvZlEnUciRPmkawPMRAW VBmtkIVFGiHqRCX911P54wS5Z6qm6Cp/VDUHwSutPtZ6MlypNgJdrtx8/aFHHVJ5V2RX NXsA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=to:subject:message-id:date:from:references:in-reply-to:mime-version :dkim-signature:arc-authentication-results; bh=fZcKW3dJn85qa9UsbaYAFgEiXjOH+QjBNfiPZTp9Yjk=; b=arTYiX1R7tWDFVIYQsBNt+w3v09el2GiKn0+3vvEB+Xs9BmSzX7QR37s3IhW4y0R7Z sf546/mNhX2ic1x0EQ+eu63sKZB1BhuBoERMU8r2ZTsIQwmeBcYPgC47MhEA+6UMIb5i XKh6swKYcKqVIYt8znZiEAQ4327AHmWXrixFf8kJuMBXsvFu9ci4UAPxEACNKDZWydzW pS0p6jjyVV6Bh08MAtqAHZcFm7FGOMVw7az5pXMmrTujYOjy5aWEqCuLBv4MSlw4l1Np h9LvrTZNxTIfbXnqmUWylOUqX9OKN63YAFiCj0HT016U4puqaElnhaSnCBIFcPWdlSKG m3cQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Epf5EDA5; spf=pass (google.com: domain of gasper.azman@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=gasper.azman@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Original-Received: from mail-sor-f41.google.com (mail-sor-f41.google.com. [209.85.220.41]) by mx.google.com with SMTPS id l12sor522194pgs.23.2018.03.27.12.56.20 for (Google Transport Security); Tue, 27 Mar 2018 12:56:20 -0700 (PDT) Received-SPF: pass (google.com: domain of gasper.azman@gmail.com designates 209.85.220.41 as permitted sender) client-ip=209.85.220.41; X-Received: by 10.101.92.139 with SMTP id a11mr467325pgt.6.1522180580019; Tue, 27 Mar 2018 12:56:20 -0700 (PDT) Original-Received: by 10.100.151.69 with HTTP; Tue, 27 Mar 2018 12:55:59 -0700 (PDT) In-Reply-To: <3dcffdf5-ea1a-41bf-87ab-1c1ddae52404@isocpp.org> X-Original-Sender: gasper.azman@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Epf5EDA5; spf=pass (google.com: domain of gasper.azman@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=gasper.azman@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=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:37502 Archived-At: --089e08268ddcc1917a05686a4840 Content-Type: text/plain; charset="UTF-8" What *is* true is that something like std::ratio would be a *great* alternative. On Tue, Mar 27, 2018 at 7:58 PM, Todd Fleming wrote: > On Tuesday, March 27, 2018 at 12:06:39 PM UTC-4, Kevin Fitch wrote: >> >> The current interface for dealing with load factor with in unordered >> containers is one of the few (only?) places in the C++ standard library >> where floating point is required even if you didn't "opt-in" to floating >> point. E.g. see http://en.cppreference.com/w/c >> pp/container/unordered_set/max_load_factor >> >> On many embedded systems hardware floating point is unavailable, and >> using software to emulate it is very expensive. Both in terms of code size >> and runtime. >> >> It should be straightforward to provide a new interface (possibly via an >> overload) for max_load_factor that takes something like a fixed point >> number. Potential interfaces include: >> >> // This would be easy to understand for those reading the docs, but >> doesn't leverage the type system very well >> // percentage would be expected to be between 0 and 100. >> void max_load_factor( int percentage ); >> >> // Or we could leverage the ratio header in a similar way to std::chrono >> // A quick/dirty version could look like: >> template > >> struct load_factor { Rep value; }; >> >> template >> int max_load_factor(const load_factor>& lf); >> >> The interface for getting the current or max load factor would be, in >> some ways, messier. I guess the functions would need new names, perhaps: >> template >> load_factor> get_max_load_factor(); >> >> template >> load_factor> get_load_factor(); >> >> Please let me know what you thing . I am by no means a C++ expert, and >> would love feedback on the best approach to this interface. But, my main >> goal is to avoid having to deal with floating point in order to get all the >> benefits of unordered containers on small/embedded systems. >> >> Kevin Fitch >> > > If you're dealing with an embedded processor without floating point, then > chances are you're doing real-time work, which means no heap allocations > after startup. The unordered containers don't fit this. > > Todd > > -- > 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/3dcffdf5-ea1a-41bf- > 87ab-1c1ddae52404%40isocpp.org > > . > -- 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/CAANG%3DkUFSXtqVre4gctWgbACtu175mYu%3DkqaGGugheQXRevt-w%40mail.gmail.com. --089e08268ddcc1917a05686a4840 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
What *is* true is that something like std::ratio would be = a *great* alternative.

On Tue, Mar 27, 2018 at 7:58 PM, Todd Fleming = <tbfleming@gmai= l.com> wrote:
On Tuesday, March 27, 2018 at 12:06:39 PM UTC-4, Kevin= Fitch wrote:
The c= urrent interface for dealing with load factor with in unordered containers = is one of the few (only?) places in the C++ standard library where floating= point is required even if you didn't "opt-in" to floating po= int. E.g. see http://en.cppref= erence.com/w/cpp/container/unordered_set/max_load_factor
<= br>On many embedded systems hardware floating point is unavailable, and usi= ng software to emulate it is very expensive. Both in terms of code size and= runtime.

It should be straightforward to provide a new interface (p= ossibly via an overload) for max_load_factor that takes something like a fi= xed point number. Potential interfaces include:

// This would be eas= y to understand for those reading the docs, but doesn't leverage the ty= pe system very well
// percentage would be expected to be between 0 and = 100.
void max_load_factor( int percentage );

// Or we could leverage th= e ratio header in a similar way to std::chrono
// A quick/dirty version = could look like:
t= emplate<class Rep, class Multiplier = =3D std::ratio<1,100> >
struct load_factor { Rep value; };=

template<class= Rep, intmax_t Num, intmax_t Denom>=
int max_load_factor(const load_factor<Rep,std::ratio<Num,Denom= >>& lf);

The interface for = getting the current or max load factor would be, in some ways, messier. I g= uess the functions would need new names, perhaps:
template<class Rep, intmax_t Num, intmax_t Denom>
load_factor<Rep,std::ratio<Num,Denom>>= ; get_max_load_factor();

template<class Rep, intmax_t Num= , intmax_t Denom>
load_fa= ctor<Rep,std::ratio<Num,Denom>> get_load_factor();<= /div>

Please let me know what you thing . I am by no means a C++ e= xpert, and would love feedback on the best approach to this interface. But,= my main goal is to avoid having to deal with floating point in order to ge= t all the benefits of unordered containers on small/embedded systems.

Kevin Fitch

If you're dealing with an em= bedded processor without floating point, then chances are you're doing = real-time work, which means no heap allocations after startup. The unordere= d containers don't fit this.

Todd

--
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-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/3dcf= fdf5-ea1a-41bf-87ab-1c1ddae52404%40isocpp.org.

--
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/CAANG%3DkUFSX= tqVre4gctWgbACtu175mYu%3DkqaGGugheQXRevt-w%40mail.gmail.com.
--089e08268ddcc1917a05686a4840-- .