220 37500 <4c98e549-8f0c-42e5-a054-0234f7cf1e46@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: kfitch42@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Remove floating point requirement for unordered (multi) set/map Date: Tue, 27 Mar 2018 09:06:39 -0700 (PDT) Lines: 133 Approved: news@gmane.org Message-ID: <4c98e549-8f0c-42e5-a054-0234f7cf1e46@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_18658_639999995.1522166799010" X-Trace: blaine.gmane.org 1522166679 7647 195.159.176.226 (27 Mar 2018 16:04:39 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 27 Mar 2018 16:04:39 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCNZV4UAUMBRBEGY5HKQKGQES36QPPY@isocpp.org Tue Mar 27 18:04:34 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vk0-f69.google.com ([209.85.213.69]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f0r5N-0001ss-Te for gclcip-std-proposals@m.gmane.org; Tue, 27 Mar 2018 18:04:34 +0200 Original-Received: by mail-vk0-f69.google.com with SMTP id z186sf15806464vkd.15 for ; Tue, 27 Mar 2018 09:06:41 -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:subject:mime-version:x-original-sender :reply-to:precedence:mailing-list:list-id:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=HOGdSQARVBh1RUMaq0yyAh4xW+Bu2guWv4skUL1Vwoo=; b=C6Nty5DxknrUH78+Xb40BlRSXVLoPXneoWx/DEpJir7JcRD6eS6bOgADa6Yhke6/88 7cMdWWQR/NH1A5P/4chNfI3QCdGqtwmMfN0QgHMhEfkkv4d8g3xNDlgLC4ME4q8y9LI2 L2/QNgnwqdUw5UH54cyIu/7M/CCjrJwtvUAhNXWM/zpi4FzdngnXaXhZ9nSQsCbdPTls 0ULh3kdr76Xg0q75M6BFypQc3lcY7jZAl0PMaYmaLFl4I9xnnveWXkzn1y9GDG9HYMwt 8tSmQeYH098dErXHoL4cDtvX8PrFeECqPiSAXf4dEeQTt7jVjSOFgtQaRQ5l3t39Bn0q WtXA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:subject:mime-version:x-original-sender :reply-to:precedence:mailing-list:list-id:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=HOGdSQARVBh1RUMaq0yyAh4xW+Bu2guWv4skUL1Vwoo=; b=YYjsQT6JkbNxofGAEzBKIrXRZdH9a3F+x00tzU3WRpmyQqVFFzCZoeUJqVGU3IlbRd zTR6lvr4inTbj+sr+Xj5CMv3qg1WYe/GURlNvuKg/uLASvXQHDK1bV6xAotur0ACTZkU ud3FJ+CvAGzsUXT5q274Hl5BwzAh3SOnued3HNHptYg5UwXmXtH/Waz+qo+LfOQthbcz BHnMSskNpfzvedmFBtR5dkhpNViqzitEIkdcwBDpFVoD/RorNJgSTEpazDUNeGT0bUuh mrgxkQCzhJ7FUWl8sJ34r6UvSlX+9qSpqVDq2NCrP5QLSv0mvjBVEwi9BVl7IabcMpta o3Qg== 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: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=HOGdSQARVBh1RUMaq0yyAh4xW+Bu2guWv4skUL1Vwoo=; b=Bl7IiXl1XITcStCvgvomiEYP0n5UMUHmCd2tL66k93r/l924lej2FibafNbr/kfZrP JAFcvTTmh5UozkFup1ToJLbuVWG5Zo/nlh9qKAbJ7LlzLt+1JnyxMErK1JpUVzhe6PtF JxpGPujcuc+ur8/VH/gZi09BzlFWWzK1mw4TYZ+UZwZrRB1fAhTMPoluos5eUGz8oEt2 bIpWke60SKmiUtbSIodffM5TyMLxXLqUDh0Eao8hEquxPgqfo+HU3pzzhC9xnNo8S9kz UZ4QEYr3iO4IbXqmuN6drAkucH8ju/fubSVmfnjH9qNQl4qdDi9NCm8t4xVzJeLHc8+Y x/pA== X-Gm-Message-State: AElRT7HPIXH42sZG3je5qttNG0T2eOn3b6qC91ZANPPm2392Opx62q7Y OCdxY73gNJzdiAZUo0lAlI+nOQ== X-Google-Smtp-Source: AG47ELsDpS2B//bTYPR7GFyPxO4bPmjveYVKBkiToxXB26db6q4mcihx82zguRsoC08d6avhLFhUGQ== X-Received: by 10.31.190.204 with SMTP id o195mr18263649vkf.98.1522166801189; Tue, 27 Mar 2018 09:06:41 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.31.153.87 with SMTP id b84ls931478vke.11.gmail; Tue, 27 Mar 2018 09:06:39 -0700 (PDT) X-Received: by 10.31.180.79 with SMTP id d76mr5449016vkf.7.1522166799562; Tue, 27 Mar 2018 09:06:39 -0700 (PDT) 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:37500 Archived-At: ------=_Part_18658_639999995.1522166799010 Content-Type: multipart/alternative; boundary="----=_Part_18659_1429057989.1522166799011" ------=_Part_18659_1429057989.1522166799011 Content-Type: text/plain; charset="UTF-8" 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/cpp/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 -- 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/4c98e549-8f0c-42e5-a054-0234f7cf1e46%40isocpp.org. ------=_Part_18659_1429057989.1522166799011 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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-i= n" to floating point. E.g. see http://en.cppreference.com/w/cpp/contai= ner/unordered_set/max_load_factor

On many embedded systems hardware = floating point is unavailable, and using software to emulate it is very exp= ensive. Both in terms of code size and runtime.

It should be straigh= tforward to provide a new interface (possibly via an overload) for max_load= _factor that takes something like a fixed point number. Potential interface= s 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 l= ook like:
templa= te<class Rep, class Multipl= ier =3D std::ratio<1,100> >
struct load_factor = { Rep value; };

templa= te<class Rep, intmax_t Num, in= tmax_t Denom>
int max_load_factor(const load_factor<R= ep,std::ratio<Num,Denom>>& lf);

The interface for g= etting the current or max load factor would be, in some ways, messier. I gu= ess 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_factor<Rep,std::ratio<Num,Denom>> get_load_factor()= ;

Please let me know what you thing . I am by no mean= s a C++ expert, and would love feedback on the best approach to this interf= ace. But, my main goal is to avoid having to deal with floating point in or= der to get all the benefits of unordered containers on small/embedded syste= ms.

Kevin Fitch

--
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/4c98e549-8f0c-42e5-a054-0234f7cf1e46= %40isocpp.org.
------=_Part_18659_1429057989.1522166799011-- ------=_Part_18658_639999995.1522166799010-- .