220 40663 article Path: news.gmane.org!.POSTED!not-for-mail From: Bryce Adelstein Lelbach aka wash 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 16:00:38 -0400 Lines: 356 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="00000000000002d6130578ae7a99" X-Trace: blaine.gmane.org 1540065526 25137 195.159.176.226 (20 Oct 2018 19:58:46 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 20 Oct 2018 19:58:46 +0000 (UTC) Cc: burningorca@gmail.com To: std-proposals@isocpp.org, =?UTF-8?Q?Jean=2DFran=C3=A7ois_Bastien?= Original-X-From: std-proposals+bncBCWL3JV7Z4FRB4USV3PAKGQEL7CU5FA@isocpp.org Sat Oct 20 21:58:42 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-io1-f69.google.com ([209.85.166.69]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gDxOT-0006OV-IL for gclcip-std-proposals@m.gmane.org; Sat, 20 Oct 2018 21:58:41 +0200 Original-Received: by mail-io1-f69.google.com with SMTP id w13-v6sf1467884iop.2 for ; Sat, 20 Oct 2018 13:00:52 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1540065651; cv=pass; d=google.com; s=arc-20160816; b=qIrmYKNxM3nSzC1H1yIWgFe8Cdt7+W5VY1Ga026TBOOmuyXVl28xtOhc6gY4yv3wCy 7Zz9fEedqpGBeVk6E0fUAGeSo/gQb89Gu/MCdxbAQEtuH+TPcLrCSJFyoUSoxCTlhfjJ smlqB7guMvJiXz9MX84VqbnfY3/ZoSleQGPAprK+cXKVTKQputbw1ab7ayzguk/B6bGx 7O4KU6g85oK3oHR6DZzsgcijgavR/wNhl3ULAWXDPfN8rJvC3mziTgQD3XhPT/HCtSvx 8sRVqXHPr012aMMmcg6hLPGMCXSBsX2b1VEunAEMbuqbw2uczyAvoQqgNBK5FHiwrlaA ixVQ== 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=uXVPBTkb6v6k4bSl5IyzWNu132aIAst6kIwukZrYKf0=; b=Yzl8wplmH6Xe3gVCLX5SFR0652kaFTlpY2+MKIoYsbFj1hsnFZ2naB73R8SrmzmlCw 957M2fAlmpU74JVKtJkQCC3fHzpWRtZ8+0vku/gVppILZss4Lt4TjtEUbaHj6j/NFLpr UlzRWdHH6qJGkDeS+mXpRxLURkIJkXILN3YhymigziDlyjhf8D5NNyAtIW+XPHXqkRJg SvlOlyQVTGLh1EE4WgV/uyOEs9PXKfDHngjLoKEuChn4UbUnVUSwtSss1G/DlOmzo5YA IMihF08SOCl+VQpyG6uUWS88luQKviacwSOF0UkvcMZ840jN0Brt5cB4s8KcIVbW7GLL MuNQ== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=QSbcPj5b; spf=pass (google.com: domain of brycelelbach@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=brycelelbach@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE 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: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=uXVPBTkb6v6k4bSl5IyzWNu132aIAst6kIwukZrYKf0=; b=tv7C7bvatPHI1XiTGN1EQnXiol5ravU+BeRzCST7YWqhHvVJeTlZyiB/tDSIB3be8w wTO7cRbTyr9VmOXLX77wHTPHxq2irGoCvVS/UT693BDNytSXdhHMO4GFC4Od8xpZDGxb L9CEUXE9H0TtCkZXODDppAVPkEIUaOO4ZOcw0FSChYmewlDSTTp0MCVtKQvisDXBNjVj 6gh/4U+Hs7oVwWtFV/lKb9+KAlRRXV8BOto4A1iEc1kB14c4k7hEDvcRb007Tho/Yegw YCccNUAzB3k/L5cy2YpqTggliw0+iSjniHgKp1wNyfSkQAZbXNW38eP6SE0nQqVIh4WQ ENvg== 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=uXVPBTkb6v6k4bSl5IyzWNu132aIAst6kIwukZrYKf0=; b=YLars4H9vN4RpmGkxwinqgpy5vWBX3ImJXnSioJXK6AWlyJkrrB+nr9PzKx1jvDENB g9UWyyseXYFgHBq3NBseiq1CEN6llfHRX0+9kAIBRf48NPcVzTQDsiRogb+XzooTs7VU JF1hzRGJcYUlG3U4nb3F4fvgq1KexBfNnLoID7YhZxFhk1hJ/HbGdbq9jhFKK5sX45gc PvvMj1EgtgvZ29eY0eYwzh7dWp3+LsKFjC7/wg07eTGykJjxr7aZfYAh3C0pYYt8Ntbe UsTCxiBujU9BJu8+1Kx2g/HVQy7boR7O5iujfJ1LY3kjVODzl8smlONidYiUOl7cuHUG s2rw== X-Gm-Message-State: ABuFfoiZLLU8VoWSDa+aS9739vYN9yYneI59wZGQjbFgBowxGw6U0B/3 hWAbc++xk4upsiiJfTJHAEQdyw== X-Google-Smtp-Source: ACcGV62ARpmXq/NKRBeN1FJhPAdJbpepbtFziJSfXKz0bLCzNIIiGtaPwIIf3awd4QEoejIs2zVZOQ== X-Received: by 2002:a24:3d14:: with SMTP id n20-v6mr7444159itn.13.1540065651876; Sat, 20 Oct 2018 13:00:51 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a02:6a15:: with SMTP id l21-v6ls11776131jac.2.gmail; Sat, 20 Oct 2018 13:00:50 -0700 (PDT) X-Received: by 2002:a02:2b29:: with SMTP id h41-v6mr6006161jaa.12.1540065650780; Sat, 20 Oct 2018 13:00:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1540065650; cv=none; d=google.com; s=arc-20160816; b=FP/bhKyKpm4aHQereuGXfhge7iapIMbf9LXKZWL0QNOrKyraPnVf42ciHC9KolVOxK hIZ0mLrEFEdfPYPmZXBT+dOd72wNih+rtB+8FCcnAkNARIq7mzUA5yhM8P2fYpxeX0Sq OAYXnE0HA7zTtXHE7/wPeQh6HzU+8mkPAduEdxe0Ozng2vXozZSMiBcJ2uJl5fvVWYBg 0lPiyHJ6BIeIrA39ss9O/bQRoQ2O7A2AyWJVNNeDufZbs6EF6SLfEyW1QdExNShxbQss DoZOMZg0bFuWGnCJra8FuWWrsQt0Mq4O7q1R1zhG0isgFpMGaTN3SKaXZWbcjnmrqJb3 tUwA== 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:dkim-signature; bh=Hyuih8pQva3eaEWJ8Y/PQZNW2cxi93LpcHhYa4rvbU8=; b=rzkD5ywdJYgOEfLvZseQhfGgL1sOMo8tOXOGuEtzkRW4FhZhtlSbkJRA6E4iRUswpJ UJAQhdkW315cGWPCdAGzGY2szvELXSl4Cszy278Smc2PLZyveNpNgWxSDzB9At0ERCS9 MlDPnOwoNHyA1GEe45LaWuu0d0obxRL8KB/3C7AUXS6bVVpYfZgbBHfkVSeceveLz7tr Pflb8+tnty7HzlsoQnnbut3pZKfbFgdiQ8l37wqBzLVs/fT6cU4Pph1dlp45L+NXfDo+ R6JBEaimZaUHjgMrXEZZYELs7PFmgLozE/EmdewwilZu9ukJopSoESC22siAxuEfmhfj RmFQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=QSbcPj5b; spf=pass (google.com: domain of brycelelbach@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=brycelelbach@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=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 h196-v6sor13099214iof.62.2018.10.20.13.00.50 for (Google Transport Security); Sat, 20 Oct 2018 13:00:50 -0700 (PDT) Received-SPF: pass (google.com: domain of brycelelbach@gmail.com designates 209.85.220.41 as permitted sender) client-ip=209.85.220.41; X-Received: by 2002:a6b:310d:: with SMTP id j13-v6mr5909826ioa.250.1540065650200; Sat, 20 Oct 2018 13:00:50 -0700 (PDT) In-Reply-To: <9d74ddbb-cc68-412a-ae6b-4664660ff12c@isocpp.org> X-Original-Sender: brycelelbach@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=QSbcPj5b; spf=pass (google.com: domain of brycelelbach@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=brycelelbach@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=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:40663 Archived-At: --00000000000002d6130578ae7a99 Content-Type: text/plain; charset="UTF-8" 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? > > 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/CAP3wax_-GqPOxaDyd1QKx40Yvj6%3DMqDn6-1cYrtUw7ObzuJcMg%40mail.gmail.com. --00000000000002d6130578ae7a99 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
JF? (See question below)

On Sat, Oct 20, 2018, 7:27 AM <burningorca@gmail.com> wrote:
I recently read that their is a pa= per 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<SignedType>::min()) become well defined behaviour?

Am = Samstag, 20. Oktober 2018 13:25:19 UTC+2 schrieb burni...@gmail.com:
But the result o= f 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 sa= me 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:

#includ= e <c= stdint>
#include <limits>
#include <iostream>#include <type_traits>

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

template<Integral ResultType, Integral ValueType>
auto abs(const ValueType s) -> ResultType
{
=C2=A0 =C2=A0 s= tatic_assert(sizeof(ResultType) > sizeof(decltype(s)) || 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 Result= Type absVal;
=C2=A0 =C2=A0
=C2=A0 =C2=A0 = if( s >=3D<= /span> 0 )
=C2=A0 =C2=A0 = {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <= span style=3D"color:#008">return <= span style=3D"color:#008">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 }<= /span>
}

in= t main(= void)
{
=C2=A0 =C2=A0 std::cout << abs<std::uint8_t>(std::numeric_limits<std::int8_t>::min()) << '\n';
=C2=A0 =C2=A0 std::cout << abs<std::int32_t>(std::numeric_limits<= /span><std<= /span>::int16_= t>::= min()) = << '\n';
=C2=A0 =C2=A0 //std::cout << abs<std::uint8_t>(std::numeri= c_limits<std::int64_t>::min()) << '\n';
=C2=A0 =C2=A0 retur= n 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 ag= ree 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 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 G= ustafsson <bengt.gu...@beamways.com&g= t; wrote:
For me t= he motivation for uabs() would more be to avoid unsigned/signed mismatch er= rors by getting the result as an unsigned (which we know it conceptually is= after abs).

I consider a numbe= r being positive as different to a number being unsigned. I'd rather th= ose two things (conversion and absolute value)=C2=A0remained separate conce= rns.

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

I'm less adverse to abs<unsigned>() bec= ause the two concerns are more apparent but only slightly.=C2=A0
=
If you're converting a float to an int, a necessary deta= il is how to approximate fractional values. So a convert<int, floor_tag&= gt;() 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 &= 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/CAP3wax_-GqPOxa= Dyd1QKx40Yvj6%3DMqDn6-1cYrtUw7ObzuJcMg%40mail.gmail.com.
--00000000000002d6130578ae7a99-- .