220 33351 article Path: news.gmane.org!.POSTED!not-for-mail From: John McFarlane Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Trait for arithmetic types similar to std::chrono::treat_as_floating_point for the use in other parts of the library Date: Wed, 26 Jul 2017 18:02:57 +0000 Lines: 149 Approved: news@gmane.org Message-ID: References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a11477fd2abfea405553c4200" X-Trace: blaine.gmane.org 1501092192 26605 195.159.176.226 (26 Jul 2017 18:03:12 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 26 Jul 2017 18:03:12 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDS7B7WQUYOBBXNS4PFQKGQEEEH6QGI@isocpp.org Wed Jul 26 20:03:08 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-wr0-f199.google.com ([209.85.128.199]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1daQeH-0006X8-0i for gclcip-std-proposals@m.gmane.org; Wed, 26 Jul 2017 20:03:05 +0200 Original-Received: by mail-wr0-f199.google.com with SMTP id p43sf28082663wrb.6 for ; Wed, 26 Jul 2017 11:03:11 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1501092191; cv=pass; d=google.com; s=arc-20160816; b=ye2zo7u7iG+MuSn3KDvxJIe4M/4C40GdV5s/KtEOxHINUOCkQ6tBzIBRdDn38D/0ga 88o2ehQ4aUG3Kew/BpOr+vcxMbiQCqlzo82ZwXUy1itiMn0jW3hTOJ/H830uHEsnAO8N 7gphGiVHzJZgcGPe3rcJZ5IhFhCh4u1+O6zmOzxpJ2P+ojuKKVReiEpATlzQXleTy7Mz q6w7/eAUq9LqeJJmmy54cSWbCmQmzUcvGPe8+ZOUTsaSoa279EBlid07qR+GrLk14TEN rBYKnh6usay02H78mWQzIclCeBfrEhwGhD9EBevE9HT4cAIU3KvNDUJhnxicjK6rqndL sJDQ== 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:in-reply-to:references:mime-version:arc-authentication-results :arc-message-signature:dkim-signature:arc-authentication-results; bh=8vA+j68ZjWqY4ks1hu3A+92jdvmNNrYANsDWEuL4kdo=; b=fn5UBABHc1tSmBPqhkr5I+ZKHRD0EQgHo+jowP7NS5GFAW0w0Yh87ZqagK8z/EIVhl UNT593YJFu7Pmm61c2pwzPhMaI+LUIfhIhEmXCgcvnCqWMDnbSbiuk01szPWG/1LMXtQ jtN6qpyEYrRcjDDNCJFQYR6n3kAkrEiu/Xs7ZwOOJtf35EtcRoPXEThbbR+vnb87Wfta dDJr2W/ftbI2z1u3V07CWqASAmFKNJakZIyqfIcUr/Kt5rUtbVx2Ahzeb1OkNLdIkTpN SWSGWibW2oSzTljmwPQwNgBoMy2R2dXxoAlAQtDsFGqwxsDC3D39Z7NnRbYRyzuMuowC y5GQ== ARC-Authentication-Results: i=2; mx.google.com; spf=pass (google.com: domain of mcfarlane.john@gmail.com designates 74.125.82.45 as permitted sender) smtp.mailfrom=mcfarlane.john@gmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to: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=8vA+j68ZjWqY4ks1hu3A+92jdvmNNrYANsDWEuL4kdo=; b=IRzmPlxtjqPusHCp+DM4PEoE8ps6P7p2CmUwjrPVjPFTzmHAz/DXWV6aj8AbnWXnxV Fh1iIF9NbDG2HSeGf/YLw9KNfE9pXDqZ5OheZ+uYqdGPa5KuYc4bQNPX0p6cpgiSzaiq /uBsGFfJZqeLQzHAh1jMhmvE60PbkLyB7vvHWg0nC1xUDD5XhuiONJ8HqLuHlx9zlQWv VvDoK+hQVTLQ9FD05aikRsSNyipg6AlTXPssKND/QdQ7UaqwKuybBmdtnIDdJxyQM0wH BBqvK4tsnE0kkpA8KzhfUAFC03w3Mf3v3arP5p7/GM4G1YGmiV5sEi3S7LGMOJ86xFDx 70bg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to: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=8vA+j68ZjWqY4ks1hu3A+92jdvmNNrYANsDWEuL4kdo=; b=b4aXMp8bQ5MAiH0k2BiInwqy0ME6hNTUIShgAN5r5Brkqvb6Zr3WQPyBb6tLxeK0wt IiV0VPvJ7xtdMpMU5Guyi+QYLdqSAmnzl84wwFkusGK4rAxZgHjU+quvjTiyJvXHfOIQ +3tihP1tkV0FTG7zISNuQ3fDI3cZNJ2LGFVMAGVeOPQeJQLzON08QcTEByyvmWzskVWb GfydQvjZsl6COAhg+Vgb/udbRn7SMVfnx5v+MYxFsHBBtktsg1auMHtTDcskzsalps38 jvpR+bjdalhAazrsiuNZ5xtapkXL56y/W1LkAh4m8ngwZkOMWXEGVpP8FiUXhAr63heA Vr5w== X-Gm-Message-State: AIVw112NmpDQtoMjpiv7mKcf6EeJz1I24Dmsct5rcnBAw0TPHmT4b/zA xHKLoVK7ozJg2g== X-Received: by 10.28.64.193 with SMTP id n184mr143235wma.19.1501092190927; Wed, 26 Jul 2017 11:03:10 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.28.55.130 with SMTP id e124ls244169wma.24.gmail; Wed, 26 Jul 2017 11:03:09 -0700 (PDT) X-Received: by 10.223.131.130 with SMTP id 2mr1697464wre.51.1501092189187; Wed, 26 Jul 2017 11:03:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1501092189; cv=none; d=google.com; s=arc-20160816; b=AAAWypgUOAwOdu0AewQrLSYnGRkk1JRm1WG0CHhDiyApMCF+pClH8EhrDf4hZW1BNU xzGM9bDTMo5YtIcy7YvLPQ3S3Dt1LIXCVANarQq9zoWZmg/oC0rq0dh//b5KdvCi2dTR qB/zAU3pgzXtxCVtbheI/M3Ppm4lbPG7uIL5tmk+AsgwBmCAmNrR22Oyhf5PlHG8EYwv ykodBB7jHfuabxn5O0OeGkVBz5QDb4bXcFPBZLjleLfLiZGDhDxhX/P8znI25DFXSYHm Fnos3B4F4mVbe+7ho6lbqBPOadW6U1hCCFlTAMiX6v8Cssxinq728jXGh2iLb7FUWTJe JdpQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :arc-authentication-results; bh=i/cRRwQD1EX0AqOMPOEybsKsjRj1i8RZ+8pFr+dJIFw=; b=fAlBykIxNAh1re8hNrunurXANsHASymXEVB1hH4wYhRp3/2D5Ch8vEtczvoZWMdkd+ 3Ie2hxB/3r0/zSsnWIEGNhwY6ZBpjH581S4tXlKmWNMaAy/S9kOd4n6J4GTEPoJXURT/ BRAW2Mk1UQa+unQx6qtT0bYVlxNK5uVkbZIwU4g3ciYVhdlZrXogTPcI5Ys05rMIC1/r n6HugIYsswF+c8FqMasePUA6lMqUmBDP5WHOvoCv+K2JwcNeRFA3iexSeY0B5Hd4G/l/ DR1D8qZXfbgorK5acz8ufnJnIrGd6EWPsDeBGLx5gR+tuLmzc1GLhP8GpgNdTS8OEOAg M1Bg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of mcfarlane.john@gmail.com designates 74.125.82.45 as permitted sender) smtp.mailfrom=mcfarlane.john@gmail.com Original-Received: from mail-wm0-f45.google.com (mail-wm0-f45.google.com. [74.125.82.45]) by mx.google.com with ESMTPS id 36si13209981wrv.297.2017.07.26.11.03.09 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Jul 2017 11:03:09 -0700 (PDT) Received-SPF: pass (google.com: domain of mcfarlane.john@gmail.com designates 74.125.82.45 as permitted sender) client-ip=74.125.82.45; Original-Received: by mail-wm0-f45.google.com with SMTP id c184so27310936wmd.0 for ; Wed, 26 Jul 2017 11:03:09 -0700 (PDT) X-Received: by 10.28.236.8 with SMTP id k8mr1360903wmh.139.1501092188518; Wed, 26 Jul 2017 11:03:08 -0700 (PDT) In-Reply-To: X-Original-Sender: john@mcfarlane.name X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of mcfarlane.john@gmail.com designates 74.125.82.45 as permitted sender) smtp.mailfrom=mcfarlane.john@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: 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:33351 Archived-At: --001a11477fd2abfea405553c4200 Content-Type: text/plain; charset="UTF-8" On Wed, Jul 26, 2017 at 9:14 AM Manuel Bergler wrote: > Hi everyone, > Hi Manual However, allowing only float, double or long double is not a restriction of > the implementation (at least in the libstdc++ one I tested). As a matter of > fact, just specializing std::is_floating_point for std::chrono::duration - > even though it is not allowed and thus undefined behaviour - makes > > ```` > using milliseconds_d = std::chrono::duration; > std::normal_distribution > distribution{milliseconds_d{0}, milliseconds_d{1}}; > ```` > > compile and the distribution yields the exact same values as it does for > pure doubles. > I'm sure that you're aware that it's a very big leap from not observing any UB in one implementation to writing code that is safe. But you might be surprised by what implementors do with the assumptions you are breaking! So I was wondering where else in the library these restrictions are kind of > arbitrary and if it does make sense to use something like > std::chrono::treat_as_floating point in other places of the library. > I would not say that they are arbitrary. It's easy to start with tight restrictions that allow basic functionality and relax them in future revisions. But it's much harder to shut the stable door once the horse has bolted. > But before searching in all of the STL for components that are > unnecessarily restrictive I first wanted to ask for feedback. > > In light of the work on the Numerics TS as outlined in [P0101r0], which > will introduce more arithmetic types to the standard library I think it > definitely makes sense to make all kinds of STL components aware of > user-defined arithmetic types, but what is your opinion? > You might be interested in P0437. It proposes moving the functionality of `numeric_limits` into individual traits -- like those in -- but continuing to allow specialization for user-defined types. The specific case of a test for floating-point is deferred but this seems to be the current approach to achieve what you're after. There are some tough problems to address here though. Firstly, while `duration` or the types from P0101 can behave like floating-point types, that does not mean that either of them are, themselves, floating-point types. They are essentially classes. So some other property may be what we're really after here: perhaps the ability to convert between floating-point types or the ability to approximate real numbers. It's difficult to say what these properties are until more types exhibit them but I hope that there is a way forward here that allows seamless interoperability between all numeric types where that makes sense. John -- 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/CABPJVnTsGJmiV3mePzgum4j_BLdcReBDXGjp4kCXCRnFDU8%2BbA%40mail.gmail.com. --001a11477fd2abfea405553c4200 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jul 26= , 2017 at 9:14 AM Manuel Bergler <berglerma@gmail.com> wrote:
Hi everyone,
Hi Manual

However, allowing only f= loat, double or long double is not a restriction of the implementation (at = least in the libstdc++ one I tested). As a matter of fact, just specializin= g std::is_floating_point for std::chrono::duration - even though it is not = allowed and thus undefined behaviour - makes=C2=A0
=C2=A0 =C2=A0
<= div>=C2=A0 =C2=A0 ````
=C2=A0 =C2=A0 using milliseconds_d =3D std::chron= o::duration<double, std::milli>;
=C2=A0 =C2=A0 std::normal_= distribution<milliseconds_d> distribution{milliseconds_d{0}, millisec= onds_d{1}};
=C2=A0 =C2=A0 ````

compile a= nd the distribution yields the exact same values as it does for pure double= s.

I'm sure that you're= aware that it's a very big leap from not observing any UB in one imple= mentation to writing code that is safe.=C2=A0 But you might be surprised by= what implementors do with the assumptions you are breaking!

<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
So I was wondering wher= e else in the library these restrictions are kind of arbitrary and if it do= es make sense to use something like std::chrono::treat_as_floating point in= other places of the library.

I would not = say that they are arbitrary.=C2=A0 It's easy to start with tight restri= ctions that allow basic functionality and relax them in future revisions.= =C2=A0 But it's much harder to shut the stable door once the horse has = bolted.
=C2=A0
But before searching in all of the STL for components that ar= e unnecessarily restrictive I first wanted to ask for feedback.
<= br>
In light of the work on the Numerics TS as outlined in [P0101= r0], which will introduce more arithmetic types to the standard library I t= hink it definitely makes sense to make all kinds of STL components aware of= user-defined arithmetic types, but what is your opinion?

You might be interested in P0437.=C2=A0 It propo= ses moving the functionality of `numeric_limits` into individual traits -- = like those in <type_traits> -- but continuing to allow specialization= for user-defined types.=C2=A0 The specific case of a test for floating-poi= nt is deferred but this seems to be the current approach to achieve what yo= u're after.

There are some tough problems to address = here though.=C2=A0 Firstly, while `duration<float>` or the types from= P0101 can behave like floating-point types, that does not mean that either= of them are, themselves, floating-point types.=C2=A0 They are essentially = classes.=C2=A0 So some other property may be what we're really after he= re: perhaps the ability to convert between floating-point types or the abil= ity to approximate real numbers.=C2=A0

It's difficult to say wh= at these properties are until more types exhibit them but I hope that there= is a way forward here that allows seamless interoperability between all nu= meric types where that makes sense.
=C2=A0
John=

--
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 h= ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CABPJVnTsGJmiV3= mePzgum4j_BLdcReBDXGjp4kCXCRnFDU8%2BbA%40mail.gmail.com.
--001a11477fd2abfea405553c4200-- .