220 33366 article Path: news.gmane.org!.POSTED!not-for-mail From: Manuel Bergler 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: Thu, 27 Jul 2017 01:18:07 +0200 Lines: 298 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="001a11408b7630588c055540a96b" X-Trace: blaine.gmane.org 1501111091 11135 195.159.176.226 (26 Jul 2017 23:18:11 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 26 Jul 2017 23:18:11 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDOZBAUFX4MRBMOG4TFQKGQEOJWTHQQ@isocpp.org Thu Jul 27 01:18:06 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yw0-f199.google.com ([209.85.161.199]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1daVZ6-0002bI-Nf for gclcip-std-proposals@m.gmane.org; Thu, 27 Jul 2017 01:18:05 +0200 Original-Received: by mail-yw0-f199.google.com with SMTP id p68sf179282833ywg.14 for ; Wed, 26 Jul 2017 16:18:10 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1501111090; cv=pass; d=google.com; s=arc-20160816; b=Du7Ma4else3p/QfvH/MvnX8CrIE0QLYU1w3ETYax7SiIuIKPbr9M3hPq+Is4GE9fmH rQ66GrfVKqnTxkpeUNtfMf+Ejpl3oDhLKkBRQml/uD0rrdrC5uxD+HJPM8hWxUWxaA1l TJLczPHNHchvzXGT8OsFbw3BlvuBbSfYNwyt8RxMbWkIm5a8mGFJYlZ2IHwOMLNr4EUn zauP3IHa0Yiql0o1uOckC8mgjuqpjurJSCdfyMhcQQx9N6US/gAVCZxPG+qPFnT4jwnQ gxGEqxIN7vxcBp/iXuRBSVfXHhPA1/AKBGkX63jLSJjryeuOsRtNkPRORCpBO6dsiemY W/cw== 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=WNqklJJ+QE8M2eqqzRLVACa3VD6fr/ym/Hqs6XXbMAs=; b=JowwDbOHhavoYBxFncwCx1N5xzBuoebGMC52pyBeo5Mc/KvedJeDV8BhRfCYsJqgUg Y6PJdFI0N6k5cCTyqiMEVtbclmx5H6tg+5chY3gY4MwQL4VEZAVFczvpr46Ub9qtD18D P2RTxTJC+6iiPuUMlwXXto2LVDz+00dkrmbvRemvVRUz0i0cHyMAAynWimT9RrB87czz D7r7jzIy4ThBOzAwpXO49aRb01/TJycOVq8ubQ6fbreo9wU3oDFqb0FBnka/ie68T2sw k7jZdZr5YSdT4fLpMk7R/ljdBhau1BaLXFOg9+NL+ZIJzHci3mLQxfRpWcWB8/dolaIE an1Q== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gmail.com header.b=CAcYSWQI; spf=pass (google.com: domain of berglerma@gmail.com designates 2607:f8b0:4003:c06::22c as permitted sender) smtp.mailfrom=berglerma@gmail.com; dmarc=pass (p=NONE sp=NONE 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=WNqklJJ+QE8M2eqqzRLVACa3VD6fr/ym/Hqs6XXbMAs=; b=HI1erSTMVmE9GSxawlfqf9Q214W2/MoRLSMgs4g4GoFcbmBv7B1y8Si+ZKf2F1Erfo rhVZy1uzUdkOI9KjQIKEfxm03TgeF+qEzAZS2WnhSAy2ak5LjEYQ0mB4mtet6fln9QdK 0vIM3aDzO10xJZYdaNd2A40FLq0As0X1jV4ZrQOtHnS92UbVhXyrwg+1h7+jTv3PtZBv F7R0sG+4LdfwP38Ti/A2EK7hP3fF1EvzmIA01jDRfjIYjvSaYj+PwMZR8lty6/v2ZTEH GV03OmSxB+Dmb+lG+woqw+AkDHqUz0OW8PjSD9xjuuQxAhyUloQ2G5CCTtzQfNBv+aPP iU5A== 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=WNqklJJ+QE8M2eqqzRLVACa3VD6fr/ym/Hqs6XXbMAs=; b=efAo1cDLfTg5xfa04RY7C4xyMPyf/rGLSHahisxpjzbhX/7G9K72apADbNCTNIDF12 HlNs2+BkeUulbS6r/UWlTX5Vh8C7uDjJa6EA8EpiiWeeMJ1rpvu9yjp1PuKTiG2o5RNl lM32f2IXI7kXyEe1z6YSCxw+0N0S/IzBYBJVV1SUxWm33y7LHiCFYJjfft8TLfZLckn1 b8QZTqmgdsvtVPR+OVOKKJnq0Fxjli2XpTbhRGpUd7dxEc15n6CGLAgs22zqof7Fp71f CXZOskiAwi6FdHGQLcKhj9iCDeFPqSlAYpLfhd8Mjr7A2Z96B5C4lnbuqPPTv/hldURX 7knw== X-Gm-Message-State: AIVw1129UU8W37WFcq07hXdnGKFZ43ldWocYAhR+3jmHBL1h6e1GBtVX pTxLLiFSe2qO5yNa X-Received: by 10.129.169.200 with SMTP id g191mr1878764ywh.21.1501111090292; Wed, 26 Jul 2017 16:18:10 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.20.6 with SMTP id 6ls1355795iou.7.gmail; Wed, 26 Jul 2017 16:18:09 -0700 (PDT) X-Received: by 10.202.1.201 with SMTP id 192mr2803212oib.163.1501111088920; Wed, 26 Jul 2017 16:18:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1501111088; cv=none; d=google.com; s=arc-20160816; b=yeUO8V5rCYYP6LLSSYHxm+Cb23jRN07YzssLp5yzOJscAE8vWgO2w78jQgEYLDoGYF uwlhODXtXhGJQeVqYmc9RG6eYdNcS/CVg1xqoUQI+ImO9dvGwFfWphmUInMkr0RSFnNd raCs4brn+a+v4Hp6BQsW/CFV4LZhJ8HltBydQRTZD+fEX32L7SSemKQC05JFgMTZwmjP LB7uu7TtvDrQM2Z0pjV0e9p0G3qTIeS3WofbVd+Qf2eFc1KJzcee+RCixPnmQ+zAznLn FO3wgwIcyMSTQrgEr8vkM2S/OtfiQBs1SdlkOPoJKeIyNcmQEjbjnKTOY1PxtGRskxJp Td0w== 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=entrHXY3VPh9LtzW38cegUv9ZOeaIsqLXGZiUsSIu3I=; b=COr/l5xdRjmP/VNCEqtr5RqQ0u0S+MAsbwTf/5mhddtOrtXVYa62RlbH52c6YLHLoD FzsO8u21KpVMNQwX4OPVUAluSkeN+IHS5AZhdpY+Wr6uWq2+uClx5Z2QkR16TM+H+Qty A+o6arS3fzHQSPl+8R7lKFE5dVoBufVtYGlmqE5FApPLEWh9JjueoTVxCb49EWjrP+4r Lq0GwT2G5G5v9S0qO796bo1pFmXV87XUgUc8GSuHetBWmyhCs3jEDrjBeTtMrVecHowu kjmXNiDkgyXMmBQohJ8H8kWj0xPCTjWzwfzF0WuJIRNg9mnKqE24bXiSzOz8vnhPllqJ 8uUw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.b=CAcYSWQI; spf=pass (google.com: domain of berglerma@gmail.com designates 2607:f8b0:4003:c06::22c as permitted sender) smtp.mailfrom=berglerma@gmail.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com Original-Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com. [2607:f8b0:4003:c06::22c]) by mx.google.com with ESMTPS id q8si9560028oih.243.2017.07.26.16.18.08 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Jul 2017 16:18:08 -0700 (PDT) Received-SPF: pass (google.com: domain of berglerma@gmail.com designates 2607:f8b0:4003:c06::22c as permitted sender) client-ip=2607:f8b0:4003:c06::22c; Original-Received: by mail-oi0-x22c.google.com with SMTP id g131so93609578oic.3 for ; Wed, 26 Jul 2017 16:18:08 -0700 (PDT) X-Received: by 10.202.226.20 with SMTP id z20mr2515733oig.242.1501111088336; Wed, 26 Jul 2017 16:18:08 -0700 (PDT) Original-Received: by 10.74.100.85 with HTTP; Wed, 26 Jul 2017 16:18:07 -0700 (PDT) In-Reply-To: X-Original-Sender: berglerma@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.b=CAcYSWQI; spf=pass (google.com: domain of berglerma@gmail.com designates 2607:f8b0:4003:c06::22c as permitted sender) smtp.mailfrom=berglerma@gmail.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=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:33366 Archived-At: --001a11408b7630588c055540a96b Content-Type: text/plain; charset="UTF-8" On Wed, Jul 26, 2017 at 8:02 PM, John McFarlane wrote: > 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! > Yes, I'm aware of that. But from a purely conceptual standpoint there is nothing that speaks against drawing milliseconds distributed according to a normal distribution, so I suspected that the mathematical formula underlying the implementation should also work for milliseconds - as it does in the case of libstdc++. But of course you're right that some optimizations that implementors might use could potentially break it. But then the more fundamental question becomes: Is it desirable to have it work for other arithmetic types. If some of the optimizations cannot be applied in the more general setting there always is the possibility for the implementors to specialize the template for these. > > 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. > This is a good point. But now that e.g. the distributions have been implemented we can get implementors feedback if these restrictions are actually used and how much of a hassle it would be to lift them. > > >> 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. > While it would work for the particular combination of std::chrono::duration and std::normal_distribution, even if we were to decide to add such a "treat as floating point" trait we need an accompanying concept so that it is clear what the library expects of a type for which the trait returns true. Some questions to consider: - Should we require all operations to be constexpr and/or noexcept? That would exclude something like Boost.Multiprecision which requires dynamic allocation or bound-checking wrappers that throw when an overflow is detected. - Does the result type of a multiplication of an arithmetic type T with a built-in floating point type have to be T again? That would exclude elastic integers and hence rationals built on top of these, but is required for accumulation. - Should we require multiplication of a built-in integer type with a arithmetic floating point type to work? That excludes Boost.Units. - Do we need implicit conversion back to the built-in type? That excludes std::chrono::duration with a floating point representation. > > 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. > > Thinking about it, maybe we even need a concept hierarchy that describes how "close" a particular arithmetic type is to built-in floating point types similar to the iterators hierarchy in order to be able to capture all cases, otherwise we'll always run into cases that conceptually "should just work" but don't due to the limitations described above. 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. > I agree. Maybe we'll even need the same thing for integral arithmetic types and then the requirements should be consistent. > > > 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 > > . > -- 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/CAM76qmu3xAdoeo4OwBZHMzisHt2%3D8D5-%3Drv9AU0VacxjSEbAGg%40mail.gmail.com. --001a11408b7630588c055540a96b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

= On Wed, Jul 26, 2017 at 8:02 PM, John McFarlane <john@mcfarlane.name= > wrote:
On Wed, Jul 26, 2= 017 at 9:14 AM Manuel Bergler <berglerma@gmail.com> 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 specializi= ng 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
=
=C2=A0 =C2=A0 ````
=C2=A0 =C2=A0 using milliseconds_d =3D std::chro= no::duration<double, std::milli>;
=C2=A0 =C2=A0 std::normal= _distribution<milliseconds_d> distribution{milliseconds_d{0}, milliseconds_d{1}};
=C2=A0 =C2=A0 ````

compile and the distribution yields the exact same values as it does for = pure doubles.

I'm su= re that you're aware that it's a very big leap from not observing a= ny UB in one implementation to writing code that is safe.=C2=A0 But you mig= ht be surprised by what implementors do with the assumptions you are breaki= ng!

Yes, I'm awar= e of that. But from a purely conceptual standpoint there is nothing that sp= eaks against drawing milliseconds distributed according to a normal distrib= ution, so I suspected that the mathematical formula underlying the implemen= tation should also work for milliseconds - as it does in the case of libstd= c++. But of course you're right that some optimizations that implemento= rs might use could potentially break it. But then the more fundamental ques= tion becomes: Is it desirable to have it work for other arithmetic types. I= f some of the optimizations cannot be applied in the more general setting t= here always is the possibility for the implementors to specialize the templ= ate for these.

S= o 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::trea= t_as_floating point in other places of the library.

I would not say that they are arbitrary.=C2=A0 It's ea= sy to start with tight restrictions that allow basic functionality and rela= x them in future revisions.=C2=A0 But it's much harder to shut the stab= le door once the horse has bolted.
<= br>
This is a good point. But now that e.g. the distributions hav= e been implemented we can get implementors feedback if these restrictions a= re actually used and how much of a hassle it would be to lift them.
=C2=A0
=C2=A0
But before searching in all of the STL for components that are u= nnecessarily 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 thin= k it definitely makes sense to make all kinds of STL components aware of us= er-defined arithmetic types, but what is your opinion?

You might be interested in P0437.=C2=A0 It p= roposes moving the functionality of `numeric_limits` into individual traits= -- like those in <type_traits> -- but continuing to allow specializa= tion for user-defined types.=C2=A0 The specific case of a test for floating= -point is deferred but this seems to be the current approach to achieve wha= t you're after.

W= hile it would work for the particular combination of std::chrono::duration = and std::normal_distribution, even if we were to decide to add such a "= ;treat as floating point" trait we need an accompanying concept so tha= t it is clear what the library expects of a type for which the trait return= s true.=C2=A0 Some questions to consider:
=C2=A0 =C2=A0 =C2= =A0- Should we require all operations to be constexpr and/or noexcept? That= would exclude something like Boost.Multiprecision which requires dynamic a= llocation or bound-checking wrappers that throw when an overflow is detecte= d.
=C2=A0 =C2=A0 - Does the result type of a multiplication of an= arithmetic type T with a built-in floating point type have to be T again? = That would exclude elastic integers and hence rationals built on top of the= se, but is required for accumulation.
=C2=A0 =C2=A0- Should= we require multiplication of a built-in integer type with a arithmetic flo= ating point type to work? That excludes Boost.Units.
=C2=A0 =C2= =A0- Do we need implicit conversion back to the built-in type? That exclude= s std::chrono::duration with a floating point representation.
=C2= =A0

There are some tough proble= ms to address here though.=C2=A0 Firstly, while `duration<float>` or = the types from P0101 can behave like floating-point types, that does not me= an that either of them are, themselves, floating-point types.=C2=A0 They ar= e essentially classes.=C2=A0 So some other property may be what we're r= eally after here: perhaps the ability to convert between floating-point typ= es or the ability to approximate real numbers.=C2=A0


Thinking about it, maybe we even need = a concept hierarchy that describes how "close" a particular arith= metic type is to built-in floating point types similar to the iterators hie= rarchy in order to be able to capture all cases, otherwise we'll always= run into cases that conceptually "should just work" but don'= t due to the limitations described above.

It's difficult to say what these properties are until more t= ypes exhibit them but I hope that there is a way forward here that allows s= eamless interoperability between all numeric types where that makes sense.<= /div>

I agree. Maybe we'll = even need the same thing for integral arithmetic types and then the require= ments should be consistent.=C2=A0

=C2=A0
John<= /div>

--
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/st= d-proposals/CABPJVnTsGJmiV3mePzgum4j_BLdcReBDXGjp4kCXCRnFDU8= %2BbA%40mail.gmail.com.

--
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/CAM76qmu3xAdo= eo4OwBZHMzisHt2%3D8D5-%3Drv9AU0VacxjSEbAGg%40mail.gmail.com.
--001a11408b7630588c055540a96b-- .