220 40654 <956410ae-7e45-43a7-ae1d-52a92aec6217@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: burningorca@gmail.com 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 04:25:19 -0700 (PDT) Lines: 413 Approved: news@gmane.org Message-ID: <956410ae-7e45-43a7-ae1d-52a92aec6217@isocpp.org> References: <3f8200be-918a-44a0-a412-6f8f43da1c51@isocpp.org> <3a5821ae-c386-46b4-8e73-4bff8764679c@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_58_848282328.1540034719166" X-Trace: blaine.gmane.org 1540034597 10291 195.159.176.226 (20 Oct 2018 11:23:17 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 20 Oct 2018 11:23:17 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCJ7BRHTYMERBIFBVTPAKGQE7HZ25MI@isocpp.org Sat Oct 20 13:23:12 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yw1-f72.google.com ([209.85.161.72]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gDpLb-0002XF-6f for gclcip-std-proposals@m.gmane.org; Sat, 20 Oct 2018 13:23:11 +0200 Original-Received: by mail-yw1-f72.google.com with SMTP id d17-v6sf2352364ywh.21 for ; Sat, 20 Oct 2018 04:25:22 -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:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=4esXOeN4SX25ou3D6tcCSYZag8wS7ghMH3H3ZmlFTeQ=; b=2IKwc/+ROObFeMpcGaebIiEdw2z/fqwfSQ4rPHJ79CSvVm8OLjeB6Y5/10m+p9NFga xmq7TIU89w3oIc87wOjlR+n+N87CUY9ziObNHd6f3Vww6FgZqbEvjVpsU3wPj9yxEugG NohA1bbiQJjewYmDGXreCcUa0kCFpQX7Rsi2apzR645Cn2QVCk6n8jh91kdKa3QxnojK MnV5GuAhc5Y563Seg3ylVaum/D1GDGx6khvljsZAI6nZNSQv5Obu8FXKaVKOmQ3jzfOH AE7JECtWevruT7vUV+3BYCmu3tmOYcUunpK12NGodoze6ywhFpbBhHOmJ5rUM2Wj32e3 ALFg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=4esXOeN4SX25ou3D6tcCSYZag8wS7ghMH3H3ZmlFTeQ=; b=lqE+pn0gmVLzPbRlINvRwKmKqOr89R4DNdI1o1nQXQcvTXUIwDqAQyUD1Vpl1rZPLL r1Ocbrb3NZyODI2XT/tZrcHJGYPYL/rdQ3lcCcc2HB641Z+K40ffZtrapzLxitqBN97P VBZtcUzvm9Vn03YnkFgE4CKL9S0qpoDZdyurccGMJrjva0gXr4NLyc7C1r8LnkgkQXBz N4i7nPLytoGMVmrj/S5SfptBmPe6gReS8ArJ5Pgu/l4NDJN1tOQbOEAyUhF2ym9TnXii dnDSuq0W3RmxEUZVloDynCCPZ7Zb2Uo4mNhDrSqjqF09xuN3k7EiCEkpkxqHWoBLfnza f/3A== 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:in-reply-to:references :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=4esXOeN4SX25ou3D6tcCSYZag8wS7ghMH3H3ZmlFTeQ=; b=gi9XM4M7eNj/2PkEI/Rx8Dz6aorKUBIlrY5Vtw8+rlLrWzEPOTLTcOWAJiNOw7gEYl 7eS+rlaZiOiMYLMFrNPt84urDUmKIEiIzrWuZM3GFQPK0sUXxkrUguqLx7zSYxSfBc58 thJsUwdJOnPat8grwkf/KoDMk8q1otA0upO6oVSlT5iupfMCJw6UUPzuwZr52OigStpz 8FrJc557aeg0ZgwwGH4VHHsu2f8QyFAWTFcbjUgDraWDligedR0swdudmtB263kJOf21 sqkYCqcl3k8g+057e6IQzL15p/FuwWOrsN5nF+wg8jk4hkb82W0u0njpQeLMHahRsPHj aIJQ== X-Gm-Message-State: ABuFfojCsT0Aext/iY8flHifmh0zEU3KjCr4DGFMmJ3b1tLx09LUWOIc iuLuBfMt4Nk6Kvkq8Q50xdKe0w== X-Google-Smtp-Source: ACcGV60lQsuLMWaWUO8Y2Dc11UNDGpz6qrt+JJKAH1fA2Ts1x7ZIJ9fWyj5WRlF/6ps95tJTn7kXbA== X-Received: by 2002:a81:230a:: with SMTP id j10-v6mr22900324ywj.15.1540034721494; Sat, 20 Oct 2018 04:25:21 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a25:bac5:: with SMTP id a5-v6ls10270431ybk.22.gmail; Sat, 20 Oct 2018 04:25:20 -0700 (PDT) X-Received: by 2002:a25:b29c:: with SMTP id k28-v6mr472408ybj.3.1540034719822; Sat, 20 Oct 2018 04:25:19 -0700 (PDT) In-Reply-To: X-Original-Sender: burningorca@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:40654 Archived-At: ------=_Part_58_848282328.1540034719166 Content-Type: multipart/alternative; boundary="----=_Part_59_483986967.1540034719167" ------=_Part_59_483986967.1540034719167 Content-Type: text/plain; charset="UTF-8" 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/956410ae-7e45-43a7-ae1d-52a92aec6217%40isocpp.org. ------=_Part_59_483986967.1540034719167 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
But the result of round, ceil and float may not resul= t 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 round are all C-function which do not have the power= of templates.

But if we would have something like= :

#include <cstdint>
#include <= limits>=
#inclu= de = <iostream><= /span>
= #include <type_traits>

template<typename T>
concept bool = Integral <= /span>=3D<= span style=3D"color: #000;" class=3D"styled-by-prettify"> std::is_integral<T>::value;

template<Integral = ResultType= , Integral ValueType>
auto abs(const = ValueType<= /span> s) -> ResultType
{
=C2=A0 =C2=A0 static_assert(sizeof(Re= sultType)<= /span> > sizeof(decltype(s)) = ||<= span style=3D"color: #000;" class=3D"styled-by-prettify"> std::is_same_v<ResultType, std::make_unsigned_t<ValueType>>, "The result type must be able to store the positive value!");
=C2=A0 =C2=A0 ResultType absVal<= span style=3D"color: #660;" class=3D"styled-by-prettify">;
=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_cast<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++;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 return absVal;
=C2=A0 =C2=A0 }
}
=
int main<= span style=3D"color: #660;" class=3D"styled-by-prettify">(void)
{
=C2=A0 =C2=A0 std::cout << abs<std::uint8_t>(std::numeric_limits<std::int8_t>::min()) <<= ; <= span style=3D"color: #080;" class=3D"styled-by-prettify">'\n';
=C2=A0 =C2=A0 std::cout << abs<std::int32_t>(std::num= eric_limits<std::int16_t>::min()) << '\n';
=C2=A0 =C2=A0 //std::cout << abs<std::uint8_t>(std::numeric_l= imits<std::int64_t>::min()) << '\n';
=C2=A0 =C2=A0 return 0;
}

it can be named abs, becau= se as the result type must be specified it is different from the existing a= bs 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 static_assert. We could also make the return type be an= y arithmetic type.
In this case floor<int>(), ceil<i= nt>() and round<int>() and maybe other similar functions could als= o be added.

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


On Sun, Oct 14, 2018, 03:31 Bengt Gustaf= sson <bengt.gu...@beamways.com> wrote:
For me the motivation for uabs() would more = be to avoid unsigned/signed mismatch errors by getting the result as an uns= igned (which we know it conceptually is after abs).

I consider a number being positive as different to a n= umber being unsigned. I'd rather those two things (conversion and absol= ute value)=C2=A0remained separate concerns.

Th= is is very similar to the annoyance of floor, round and ceil returning floa= ts which we know have integer values, forcing us to write int(round(x)) whe= n using this with other ints to avoid compiler warnings. I think I saw some= thing about new floor<int>() and similar functions being proposed, so= why not uabs?

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

If you're convert= ing a float to an int, a necessary detail is how to approximate fractional = values. So a convert<int, floor_tag>() starts to become palatable. p0= 105 proposed something similar. I'm not familiar with the floor functio= n you mention.

--
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-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/956410ae-7e45-43a7-ae1d-52a92aec6217= %40isocpp.org.
------=_Part_59_483986967.1540034719167-- ------=_Part_58_848282328.1540034719166-- .