220 40664 article Path: news.gmane.org!.POSTED!not-for-mail From: JF Bastien Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Function to compute the absolute value of any integral value including signed minimums Date: Sat, 20 Oct 2018 15:52:29 -0700 Lines: 418 Approved: news@gmane.org Message-ID: References: <3f8200be-918a-44a0-a412-6f8f43da1c51@isocpp.org> <3a5821ae-c386-46b4-8e73-4bff8764679c@isocpp.org> <956410ae-7e45-43a7-ae1d-52a92aec6217@isocpp.org> <9d74ddbb-cc68-412a-ae6b-4664660ff12c@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000009548b10578b0e0e0" X-Trace: blaine.gmane.org 1540075840 9701 195.159.176.226 (20 Oct 2018 22:50:40 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 20 Oct 2018 22:50:40 +0000 (UTC) Cc: std-proposals@isocpp.org, burningorca@gmail.com To: Bryce Adelstein Lelbach Original-X-From: std-proposals+bncBCL7ZLPGHAILXY5O3YCRUBF3DX272@isocpp.org Sun Oct 21 00:50:35 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-lj1-f197.google.com ([209.85.208.197]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gE04o-0002Q6-Oz for gclcip-std-proposals@m.gmane.org; Sun, 21 Oct 2018 00:50:34 +0200 Original-Received: by mail-lj1-f197.google.com with SMTP id h82-v6sf11298536ljh.16 for ; Sat, 20 Oct 2018 15:52:45 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1540075965; cv=pass; d=google.com; s=arc-20160816; b=mSnr+FgSE3A3wvzi3B2GKztOnwz+054IhgVvIge299+5/7chDYDF1atWYQYINWMH0U 5jJ4u1TPsp7nbau1/7M6pGiCASxSjr4ZHo2c7vAxrGLdNqPxBfmqoQ0joQsHpDdrfFh6 e+7ANVlhxapvPqgT5WsaTv76SON+crkZZP7phVyYkUF9K07H2dtHzNV8uQsvzy/QiWYg qQZBQEhvXoL03f2b+EVsVdT83jOpBWAXuNEtwvb0wNHdmoE3nYoBo8dhKvzszK8MqJPz AQJRHLL6PhqtLRIp5s1iBulo4QFFibOolbuBY8t0adiYImKONw2iStoXvidWRxqBgd3T UdAA== 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:cc:to:subject:message-id :date:from:in-reply-to:references:mime-version:dkim-signature; bh=ML4+OAxS7RQZzdWVaKzX7YQJUIymbZgCWx8JXp0oN1M=; b=U4fAVgH1XFyfBZq21kMj4HnI7PdpJWRE7N4609OKeOjofpNxVuAM7zLR2qu0IFd4A6 P1nBI+oBtyHJdFyoBhm9pZ3GnEH4Kk35hfPdwyHBgi1uacRTCSJLt3vwCxULWReEmykh eMo1Ku+E2+/mTG9E2o7laKg//Ciyf4Bs+0TlVOG/QPgcWG/zYxQB+QYLZi4srhyAo1Tk 9ox3P1mpn25/Zr6ntIDP4RQJLvzNBGC21Phd7BPv6bDCH/ahzn+EUUhWlxX6TmzRYAW9 +dhN8m0uxmnPWRtvAyb2vyiTdPczyb/cfD0OO66SXWvQ5Px8BWs0T+sQC2ANMOL8z4dm +6nA== ARC-Authentication-Results: i=2; mx.google.com; spf=pass (google.com: domain of bourgeoisie@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=bourgeoisie@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 :cc: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=ML4+OAxS7RQZzdWVaKzX7YQJUIymbZgCWx8JXp0oN1M=; b=KxHpfuNvFvSjEhdU5h0Wjm8NOTRXalNNqRuCj0BDYgEXPlsjHh39Cq4bJ1wbYz537F OuXjByfO0+GgNd/iykNceDRNY7oI3jFY43V5mpm/8lMbktX4GPvgqVOBAtiMjKCFxF5R QQX8bMmsgq8JFB07VeOy2Fev3IYkdR5tDY+CHzI6nxQCJczzoJsQRGVvA7s6OF54QTD+ oAbBPGRS/6LmwkJSabYZ+WOngUyKazpf6FFEUaAnByMuGFLdSkrLb1LuqPk/AnCFECjS J861yfw6yVbPaZLfg/54r9/OQ4ONXO6w67XkTnCgaBFF96xk1LexC6pwbHifxnDasUbj YKEw== 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:cc: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=ML4+OAxS7RQZzdWVaKzX7YQJUIymbZgCWx8JXp0oN1M=; b=cEJYLADuTIbwVs+vctiSJFGbGJCMVKWAQ6FV1GZx9sEtG6zsW9OXCMNkl9Xr8f5aAG 8vnM3qxkNtFnsJWPgalQO+BFnaMprepNlletyxensXlM3eDHBa+xLGIz7DfAKKmsc9vO A2LSmzLqJ4Pp3wdvI5CNKkISJJlOr2n7f2jmmLbJgf3WiJItIqF7ZAMF4o3+EfRC2o6F yyEy21BZ6jSD81Qy6wkSmKA+qSM/TJgy746q77NIExx5eBSIFSXIJ5NOS12y/oCAmwk4 2SRt3yE3Di4zU6UmaEWJeDS5VKOGu/ZU9CNU9WSAWoQqU5d1dVBJBNv/KXyaT+pvtPLP nviA== X-Gm-Message-State: ABuFfogz+EAi3z28XZ5zUxRf1utlRagZ26Dt6A7+UCJvzHpDQ0DsRVcf m+stkujygA0su2T2NMUkad0= X-Google-Smtp-Source: ACcGV632izhfJVNwspB6+7YK1WWAI55WaF1omhE6XcmILJDJUawA65YzSceme6c2+FSmyLBYLYXIbA== X-Received: by 2002:a19:d767:: with SMTP id o100-v6mr339152lfg.33.1540075965088; Sat, 20 Oct 2018 15:52:45 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a19:ca43:: with SMTP id h3-v6ls1203501lfj.40.gmail; Sat, 20 Oct 2018 15:52:43 -0700 (PDT) X-Received: by 2002:a19:e30f:: with SMTP id a15mr618832lfh.66.1540075963031; Sat, 20 Oct 2018 15:52:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1540075962; cv=none; d=google.com; s=arc-20160816; b=EKVBSOn+tbJKnCWYz1JcRtXrdVZHjmuy82i0QjrQBX2D4LW9cHKKbH3cOEjsQqgppr pozW3ugqCTZWpl/0yTuVISUwMWs2D8STatz8qNsboouH2xe4ztl4MqGxldewQSXBPfQb +y/8Xj3A3jNPgLoELmhkk1sRf0ZgP6oxniSvqZ8ssbU3p8zPNscNNNZNOM9dt4Qrb5Lm CPAeGau+WM64QRSfgF9ej+fR/pFE02H2wv/24ULn9Ka9KS6ZNCACYjqelRbV+kqGcpHB jdYvekUx6gMcIInPL5h9qYaXb/1WcnlYn7nmYOTNP+aUt2kfqp3MfCJZ5mca5OFfyAmr Iy2Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version; bh=PuBRrefg5Xi/BngOlmyowwmeQ51ZTRhb5seyFNLS4G0=; b=hRUpxPq+yjE5CMupkm31u4OS1iX2eZVq5IyYw5giGwoPVFAwaOFUslh1392d+ZR4Q2 WlJ0fqNO5fjj9k5ILBpG9KnegXZPcIKvWJPgRBNSyqRcNtfm+nNcCOSfXyQOXVJLwYnZ Ev50C4qbGpE3Ken9YLYJ5l0Omxj95rH3FD1d7CMcRTvZJOvWRG1/simLE19WFcTcmivp zMk6GVrF/5yC5yLYtrtEI9uYEAwZy6jRxDV0mw6I6mtZICDchwbS7DU/7FG1L3LI2lUj Inbh1m8BTeBake45AcOGUF0bP6Y7+O+4PyxogUmXyAaqpfE9W3n5DnY0O8WeC8SEDssk r3tA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of bourgeoisie@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=bourgeoisie@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 p199-v6sor8670126lfe.22.2018.10.20.15.52.42 for (Google Transport Security); Sat, 20 Oct 2018 15:52:42 -0700 (PDT) Received-SPF: pass (google.com: domain of bourgeoisie@gmail.com designates 209.85.220.41 as permitted sender) client-ip=209.85.220.41; X-Received: by 2002:a19:4f04:: with SMTP id d4-v6mr5777338lfb.121.1540075962128; Sat, 20 Oct 2018 15:52:42 -0700 (PDT) Original-Received: from mail-lj1-f172.google.com (mail-lj1-f172.google.com. [209.85.208.172]) by smtp.gmail.com with ESMTPSA id h9-v6sm6006184ljg.8.2018.10.20.15.52.41 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 20 Oct 2018 15:52:41 -0700 (PDT) Original-Received: by mail-lj1-f172.google.com with SMTP id z21-v6so33808638ljz.0 for ; Sat, 20 Oct 2018 15:52:41 -0700 (PDT) X-Received: by 2002:a2e:501c:: with SMTP id e28-v6mr7790936ljb.45.1540075961007; Sat, 20 Oct 2018 15:52:41 -0700 (PDT) In-Reply-To: X-Gmail-Original-Message-ID: X-Original-Sender: cxx@jfbastien.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of bourgeoisie@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=bourgeoisie@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:40664 Archived-At: --0000000000009548b10578b0e0e0 Content-Type: text/plain; charset="UTF-8" On Sat, Oct 20, 2018 at 1:00 PM Bryce Adelstein Lelbach aka wash < brycelelbach@gmail.com> wrote: > JF? (See question below) > > On Sat, Oct 20, 2018, 7:27 AM wrote: > >> I recently read that their is a paper suggesting integers always being >> twos complement should be standardised. If this is the case, would the call >> to the existing std::abs(std::numeric_limits::min()) become >> well defined behaviour? >> > http://wg21.link/p0907 *Status-quo* If a signed operation would naturally produce a value that is not within the range of the result type, the behavior is undefined. The author had hoped to make this well-defined as wrapping (the operations produce the same value bits as for the corresponding unsigned type), but WG21 had strong resistance against this. > Am Samstag, 20. Oktober 2018 13:25:19 UTC+2 schrieb burni...@gmail.com: >>> >>> But the result of round, ceil and float may not result in a value that >>> is able to be stored in an integer. The result of abs can always be stored >>> in unsigned same type or any greater type. >>> abs, floor, ceil and round are all C-function which do not have the >>> power of templates. >>> >>> But if we would have something like: >>> >>> #include >>> #include >>> #include >>> #include >>> >>> template >>> concept bool Integral = std::is_integral::value; >>> >>> template >>> auto abs(const ValueType s) -> ResultType >>> { >>> static_assert(sizeof(ResultType) > sizeof(decltype(s)) || std:: >>> is_same_v>, "The result >>> type must be able to store the positive value!"); >>> ResultType absVal; >>> >>> if( s >= 0 ) >>> { >>> return static_cast(s); >>> } >>> else >>> { >>> absVal = ~s; >>> absVal++; >>> return absVal; >>> } >>> } >>> >>> int main(void) >>> { >>> std::cout << abs(std::numeric_limits::min >>> ()) << '\n'; >>> std::cout << abs(std::numeric_limits:: >>> min()) << '\n'; >>> //std::cout << >>> abs(std::numeric_limits::min()) << '\n'; >>> return 0; >>> } >>> >>> it can be named abs, because as the result type must be specified it is >>> different from the existing abs overloads and thus does not need a new name. >>> So I agree to abs(); >>> And if you do not care about safety you could even leave out the >>> static_assert. We could also make the return type be any arithmetic type. >>> In this case floor(), ceil() and round() and maybe other >>> similar functions could also be added. >>> >>> Am Sonntag, 14. Oktober 2018 17:18:09 UTC+2 schrieb John McFarlane: >>>> >>>> >>>> >>>> On Sun, Oct 14, 2018, 03:31 Bengt Gustafsson >>>> wrote: >>>> >>>>> For me the motivation for uabs() would more be to avoid >>>>> unsigned/signed mismatch errors by getting the result as an unsigned (which >>>>> we know it conceptually is after abs). >>>>> >>>> >>>> I consider a number being positive as different to a number being >>>> unsigned. I'd rather those two things (conversion and absolute >>>> value) remained separate concerns. >>>> >>>>> >>>>> This is very similar to the annoyance of floor, round and ceil >>>>> returning floats which we know have integer values, forcing us to write >>>>> int(round(x)) when using this with other ints to avoid compiler warnings. I >>>>> think I saw something about new floor() and similar functions being >>>>> proposed, so why not uabs? >>>>> >>>> >>>> I'm less adverse to abs() because the two concerns are more >>>> apparent but only slightly. >>>> >>>> If you're converting a float to an int, a necessary detail is how to >>>> approximate fractional values. So a convert() starts to >>>> become palatable. p0105 proposed something similar. I'm not familiar with >>>> the floor function you mention. >>>> >>>>> >>>>> -- >>>>> 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-proposal...@isocpp.org. >>>>> To post to this group, send email to std-pr...@isocpp.org. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/3a5821ae-c386-46b4-8e73-4bff8764679c%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/9d74ddbb-cc68-412a-ae6b-4664660ff12c%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/CACeCrotMrChHSoswwYpxqRfd9OR2Fsfoz05RwOm3w%2BaEBqEGQw%40mail.gmail.com. --0000000000009548b10578b0e0e0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, Oct 20, 2018 at 1:00 PM Bryce Adelstein Lelbach aka wash= <brycelelbach@gmail.com&g= t; wrote:
JF? (See question below)

On Sat, Oct 20, 2018, 7:27 AM <burningorca@gmail.com> wrote:
<= /div>
I r= ecently read that their is a paper suggesting integers always being twos co= mplement should be standardised. If this is the case, would the call to the= existing std::abs(std::numeric_limits<SignedType>::min()) become wel= l defined behaviour?
Status-quo<= /em>=C2=A0If a signed operation would naturally produce a value that is not w= ithin the range of the result type, the behavior is undefined. The author h= ad hoped to make this well-defined as wrapping (the operations produce the = same value bits as for the corresponding unsigned type), but WG21 had stron= g resistance against this.


=C2=A0<= /div>
A= m Samstag, 20. Oktober 2018 13:25:19 UTC+2 schrieb burni...@gmail.com:<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
But = the result of round, ceil and float may not result in a value that is able = to be stored in an integer. The result of abs can always be stored in=C2=A0= unsigned same type or any greater type.
abs, floor, ceil and rou= nd are all C-function which do not have the power of templates.
<= br>
But if we would have something like:

#include <cstdint>
#include <l= imits>
#include <iostream>
#include <type_traits>

template<typename T>
concept = bool Integral =3D std::is_integral<T= >::value;

template<Integral ResultType, Integral ValueType>
auto abs(<= span style=3D"color:rgb(0,0,136)">const ValueType s) -> ResultType
<= /span>{
=C2=A0 =C2=A0 static= _assert(sizeof(ResultType) > <= /span>sizeof(decltype<= span style=3D"color:rgb(102,102,0)">(s)) || std:= :is_same_v<ResultTy= pe, std::make_unsigned_t<ValueType= >>, "The result type= must be able to store the positive value!");
=C2=A0 =C2= =A0 ResultType absVal;=
=C2=A0 =C2=A0
=C2=A0 =C2=A0= if( s >=3D = 0 )
=C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 return static_cas= t<ResultType>= ;(s);
=C2=A0 =C2=A0 }
=C2=A0 =C2=A0 else
=C2=A0 =C2=A0 {
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 absVal =3D= ~s;
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 absVal++;<= /span>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 return absVal;
=C2=A0 =C2=A0 }
}
int main(void)
{
=C2=A0 =C2=A0 s= td::cout << abs<std::uint8_t= >(std::numeric_limits<std::int8_t= >::min()) = << '\n';
=C2=A0 =C2=A0 std::cout = << abs<std::int32_t>(std<= /span>::numeric_limits<std::int16_t>::mi= n()) << &= #39;\n';
=C2=A0 =C2=A0 //std::cout << abs<std::uint8_t>(std::numeric_limits<= std::int64_t>::min()) << '\n';
=C2=A0 =C2=A0 ret= urn 0;
}

it can be named abs, because as the result type= must be specified it is different from the existing abs overloads and thus= does not need a new name.
So I agree to abs<unsigned>();
And if you do not care about safety you could even leave out the s= tatic_assert. We could also make the return type be any arithmetic type.
In this case floor<int>(), ceil<int>() and round<= ;int>() and maybe other similar functions could also be added.

= Am Sonntag, 14. Oktober 2018 17:18:09 UTC+2 schrieb John McFarlane:

On Sun, Oct 14, 2018, 03:31 Bengt Gustafsson <bengt.gu...@beamways.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
For me th= e motivation for uabs() would more be to avoid unsigned/signed mismatch err= ors by getting the result as an unsigned (which we know it conceptually is = after abs).

I consider a number= being positive as different to a number being unsigned. I'd rather tho= se two things (conversion and absolute value)=C2=A0remained separate concer= ns.

This is very similar to= the annoyance of floor, round and ceil returning floats which we know have= integer values, forcing us to write int(round(x)) when using this with oth= er ints to avoid compiler warnings. I think I saw something about new floor= <int>() and similar functions being proposed, so why not uabs?
<= /div>

I'm less adverse to abs<= unsigned>() because the two concerns are more apparent but only slightly= ..=C2=A0

If you're converting a float to an int= , a necessary detail is how to approximate fractional values. So a convert&= lt;int, floor_tag>() starts to become palatable. p0105 proposed somethin= g similar. I'm not familiar with the floor function you mention.
<= div class=3D"gmail_quote">

--
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-proposal...@isocpp.org.
To post to this group, send email to std-pr.= ...@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/= std-proposals/3a5821ae-c386-46b4-8e73-4bff8764679c%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-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-propo= sals/9d74ddbb-cc68-412a-ae6b-4664660ff12c%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 h= ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACeCrotMrChHSo= swwYpxqRfd9OR2Fsfoz05RwOm3w%2BaEBqEGQw%40mail.gmail.com.
--0000000000009548b10578b0e0e0-- .