220 33367 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: Thu, 27 Jul 2017 01:16:41 +0000 Lines: 220 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="001a11472a56d8f89c055542512a" X-Trace: blaine.gmane.org 1501118217 5606 195.159.176.226 (27 Jul 2017 01:16:57 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 27 Jul 2017 01:16:57 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDS7B7WQUYOBBBP64TFQKGQE3AHV6LI@isocpp.org Thu Jul 27 03:16:53 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-lf0-f71.google.com ([209.85.215.71]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1daXQ1-0000zU-En for gclcip-std-proposals@m.gmane.org; Thu, 27 Jul 2017 03:16:49 +0200 Original-Received: by mail-lf0-f71.google.com with SMTP id w199sf40517478lff.2 for ; Wed, 26 Jul 2017 18:16:55 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1501118215; cv=pass; d=google.com; s=arc-20160816; b=ua0U8v089oStgpSQ24TpZsvzHDQk0xlqkrNNLRdaHt1+FKXbWuVEpIeWfa9uHatGJa gof08BrIbqIQ0lDX9trSyKqZMI2tUMdaQOLnVcQ5v51keVH8nJWEbUZlkdYH3toHkwGW OxJ53k9hn1aVpUZU7FoEtxSeL6MCFjyfR+QE6KsC6QCCUt8FE9fS3/zUXTXLDTgsOsW1 q4SFHv3Df7z8Eq4oa9RIyXSmGvf166Lvl5l2dxYXeA7N06pFLZhG+Y90M6k7BuFZnNfP e2X8xKiMmm80QQw0CuLt4r4c6MjM5nCO3UPP2ZFHbjF+MRlUCCeql2BSTqeuRMFapfGW /SsA== 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=a5H7cetx5OdQQIAP0+V4Ii3Mm4rT7CSN8cwXx8sfUM8=; b=caXh/m97b0etpdxunkjvsd08wMyjwPdiselzc2vqb3Fs4IeExrszMRRbHFx59ifBCM JdppKF9IXA/DDFP37cNjkFaTcjGSauhvhHs97Q9V+z62NX43lyadhM8TeMmbd59knnQ4 34Rkj/VDXpkJnBMDp2RXcsn4Sap+Obs/zM8oIdjo2U/fYon1/diYs+nZYCf673y3vhDN Z51zFu+VJlBdV+Oa4MNbpPGL8AJx6NzuyhDnJFN0LXPZX2oCQWlmMUfsvH8KJKt9lrhX 2DlleTludVStnfnVaKlWi+VO8KDX52XyNwEZ5I/bPUVwVzFVBpd8nu18rLtILZ76VyqJ LzJw== ARC-Authentication-Results: i=2; mx.google.com; spf=pass (google.com: domain of mcfarlane.john@gmail.com designates 74.125.82.52 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=a5H7cetx5OdQQIAP0+V4Ii3Mm4rT7CSN8cwXx8sfUM8=; b=grL0Cm8mgd6/HcQJkaEhvGkKoa8OiNPU+wBWhSWtrOvHUpDf7NzZFzYCjnAMXDnNsE i8/7qS5CegsI7xYzD4yPoJQmXDLRb8yQW5BIPJEHSGptxCHRhQsaRutkeJVcaDoXRnQM 0OqiamyAOpPmWhZmAPY/VfaK8910UYtoQM/AhqPqD31daGkDHRtu1zFyQ5YriQ0CoYod qaR97xEN1Wz5vOySCcd7UKbxddB1wghuUXl8UWWfZmFrr/ItA96hAPr6xSTPgJ/7irzT +JUc2VCraGo2j+GG9cBV0VuplAdxzUEyQn7dUgBot0n0TQDoD4eoAIlKslM0f1VzMVHV iL8g== 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=a5H7cetx5OdQQIAP0+V4Ii3Mm4rT7CSN8cwXx8sfUM8=; b=MddQ3PgCO/aVFJR0AZ1yaBbuUGH7bDkujyEomOB6kMwpWJoc94fE8rKFzjitNE694g FTsRxlyt4jr2whgTDpPxwBIVnuZMS8IaG5PZiTruDehYOOi7utJ6wHFqMzFdxEFfHoXd RMFFvMonlEbvC+ESV5NpffD9Efmp6mGtY9o8CxMpsJ79k6s6ZDvZoydgpaDF/7dUa+rQ YTZkMnuhnXDc+pskIo6O4GuhX8d8vedfkRCpG8ppEdfHWURO5oqgJXikVF2MibSPbrH5 02J+5DHnoInCuBvTnezBlwBqG5qkwgMWwYxKSG9Mig+ORUkhCkIMvqNZg5Na9j2wXzTF fp1w== X-Gm-Message-State: AIVw1109yxefgiTSsOCW1YifTnjKGjRhf2tfG2XacRr/FhTOAydGiwBE FVtTxL9XsoRV4A== X-Received: by 10.46.21.65 with SMTP id 1mr417211ljv.8.1501118215353; Wed, 26 Jul 2017 18:16:55 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.28.135.138 with SMTP id j132ls359598wmd.13.gmail; Wed, 26 Jul 2017 18:16:53 -0700 (PDT) X-Received: by 10.223.146.35 with SMTP id 32mr2074066wrj.76.1501118213617; Wed, 26 Jul 2017 18:16:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1501118213; cv=none; d=google.com; s=arc-20160816; b=mApdXsWSvnBHaNF0Yf0vHmDLgkEO8whOL5awsLw6nxIFbWf31Ut9dQbnq/DzaaPRYN kECyQXVUgbJvKfFkRkB2PF3EBVeSahEqn7Err+CWhjsqreCzzKNttdirtQeSyAUlEzZw GXzqSVjgL94gSigWo5UN3PEGXONcINwRMzLpUphmkGMJkqTYOCbbv3pI7FvpP2KuvSiJ H8Ck/zrzY3J7FApYlIToLN/tYOPOG6ax3+o4XM8MgbJfCJymjGbkSwrbK+8RFJLOwOvx RlTF+IeWTjH9ybCQ6A6r+lOoDoGIO1M9sYvRh4bCbau5UQZG4KXeOoqIaXuVeCG8gapP OftQ== 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=3wfpoBZHaM9Kbodw3zIwQPnkUb/xe7EWQVucF7p82Nk=; b=qHMUNEPxEj90LF34EoDOgMCOLq5oXvhFEw1ExFyVOFeEk9xN2IdGKXQQRKkq4rGa/p Au3V3+AXni7IClvdFy3JFtj7BOLvSIt44iEprRPpne8k6Qk51fW33SXQaNQD3K/3f49q 7GNGBh5drFCCq46ef6vLvS4PnAnboDkaZnHFcl55CP0bt5LEnqNR40vOfCtUaDPU3K4+ to+vgfZHEdn97UQwAfMnzwa2rXbBPMdeBzwDzIdVOgp7jpENU8BRaYeIwNVuDJWVEOE1 11mYzlY+VRS8i8L1zFpy2B+jKiJJggMVbtpZx2ECK7mPp5Qf9NhQX64kZdfvzeR1NiGK AD8g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of mcfarlane.john@gmail.com designates 74.125.82.52 as permitted sender) smtp.mailfrom=mcfarlane.john@gmail.com Original-Received: from mail-wm0-f52.google.com (mail-wm0-f52.google.com. [74.125.82.52]) by mx.google.com with ESMTPS id r129si863211wmg.261.2017.07.26.18.16.53 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Jul 2017 18:16:53 -0700 (PDT) Received-SPF: pass (google.com: domain of mcfarlane.john@gmail.com designates 74.125.82.52 as permitted sender) client-ip=74.125.82.52; Original-Received: by mail-wm0-f52.google.com with SMTP id c184so29262782wmd.0 for ; Wed, 26 Jul 2017 18:16:53 -0700 (PDT) X-Received: by 10.28.111.206 with SMTP id c75mr667936wmi.36.1501118212927; Wed, 26 Jul 2017 18:16:52 -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.52 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:33367 Archived-At: --001a11472a56d8f89c055542512a Content-Type: text/plain; charset="UTF-8" On Wed, Jul 26, 2017 at 4:18 PM Manuel Bergler wrote: > On Wed, Jul 26, 2017 at 8:02 PM, John McFarlane > wrote: > >> On Wed, Jul 26, 2017 at 9:14 AM Manuel Bergler >> wrote: >> >>> 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. > I've not found these to be a major issue. The same literal type instantiated with `Boost.Multiprecision` becomes no longer literal but continues to work well in run-time expressions. As for `noexcept`, one has to provide an expression to the `noexcept` specifier which typically replicates the body of the function. This is unfortunate but I believe that it can be added to an existing interface without breaking it. - 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. > Generally no. It's really up to the wrapping class -- in this case `duration`. Doesn't this also exclude `int`? > - Should we require multiplication of a built-in integer type with a > arithmetic floating point type to work? That excludes Boost.Units. > I don't really have enough experience of Boost.Units to comment other than to say it has some pretty obvious restrictions. An example might help. > - Do we need implicit conversion back to the built-in type? That > excludes std::chrono::duration with a floating point representation. > Again, it depends. Units, is a great example of where implicit conversions are typically a big no-no. Many 'safe' types are also. But for a wrapper that is trying to be agnostic about what it is wrapping, I believe it should generally match with whatever the behavior of the wrapped type is, i.e. if `T` allows implicit conversion, then `Wrapper` should seriously consider allowing implicit conversion also. > > >> >> 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. > I'm not at all clear about whether it is possible or wise to conceptify numeric types. It may be that individual operations/member functions of outer types such as `duration` need to stipulate quite specific requirements on a case-by-case basis. 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/CABPJVnQBg5ZBV2U-i7e4pNMJYkgJNyijWmps-58aAVZK%2BS-%2BeA%40mail.gmail.com. --001a11472a56d8f89c055542512a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jul 26= , 2017 at 4:18 PM Manuel Bergler <berglerma@gmail.com> wrote:
On Wed, Jul 26, 2017 at 8:02 PM, John McFarlane <john@= mcfarlane.name> wrote:
On Wed, Jul 26, 2017 at 9:14 AM Manuel Bergler <berglerma@gmail.com> wrote:
In li= ght of the work on the Numerics TS as outlined in [P0101r0], which will int= roduce more arithmetic types to the standard library I think it definitely = makes sense to make all kinds of STL components aware of user-defined arith= metic types, but what is your opinion?
=

You might be = interested in P0437.=C2=A0 It proposes 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 speci= fic 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 par= ticular 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.=C2=A0 Some questions t= o consider:
=C2=A0 =C2=A0 =C2=A0- Should we require all oper= ations to be constexpr and/or noexcept? That would exclude something like B= oost.Multiprecision which requires dynamic allocation or bound-checking wra= ppers that throw when an overflow is detected.

I've not found these to be a major is= sue.=C2=A0 The same literal type instantiated with `Boost.Multiprecision` b= ecomes no longer literal but continues to work well in run-time expressions= ..=C2=A0 As for `noexcept`, one has to provide an expression to the `noexcep= t` specifier which typically replicates the body of the function.=C2=A0 Thi= s is unfortunate but I believe that it can be added to an existing interfac= e without breaking it.

<= div dir=3D"ltr">
=
=C2=A0 =C2=A0 - Does the result type of a multiplication of an arithme= tic type T with a built-in floating point type have to be T again? That wou= ld exclude elastic integers and hence rationals built on top of these, but = is required for accumulation.

Generally no.=C2=A0 It's really up to the wrapping cla= ss -- in this case `duration`.=C2=A0 Doesn't this also exclude `int`? = =C2=A0
=C2=A0
=C2=A0 =C2=A0-= Should we require multiplication of a built-in integer type with a arithme= tic floating point type to work? That excludes Boost.Units.

I don't really have enough exp= erience of Boost.Units to comment other than to say it has some pretty obvi= ous restrictions.=C2=A0 An example might help.
=C2=A0
=C2=A0 =C2=A0- Do we need implicit conversion bac= k to the built-in type? That excludes std::chrono::duration with a floating= point representation.

<= div>Again, it depends.=C2=A0 Units, is a great example of where implicit co= nversions are typically a big no-no.=C2=A0 Many 'safe' types are al= so.=C2=A0 But for a wrapper that is trying to be agnostic about what it is = wrapping, I believe it should generally match with whatever the behavior of= the wrapped type is, i.e. if `T` allows implicit conversion, then `Wrapper= <T>` should seriously consider allowing implicit conversion also.
=C2=A0

<= /div>
There are some tough problems to address here though.=C2=A0 First= ly, while `duration<float>` or the types from P0101 can behave like f= loating-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 o= ther 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.=C2=A0


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

I= 'm not at all clear about whether it is possible or wise to conceptify = numeric types.=C2=A0 It may be that individual operations/member functions = of outer types such as `duration` need to stipulate quite specific requirem= ents on a case-by-case basis.=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 https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CABPJVnQBg5ZB= V2U-i7e4pNMJYkgJNyijWmps-58aAVZK%2BS-%2BeA%40mail.gmail.com.
--001a11472a56d8f89c055542512a-- .