Topic: About N3965: Proposal for Unbounded-Precision
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Wed, 12 Mar 2014 19:57:15 +0100
Raw View
This is a multi-part message in MIME format.
--------------070009060207040003070102
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 12/03/14 12:19, Vincent Reverdy a =C3=A9crit :
> Hello.
>
> I have some questions about N3965:=20
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3965.html
> It is great without doubt, to standardize big integers. They have been=20
> used for a long time with libraries like GMP and there is a lot of=20
> existing practice and experience with them.
> However I have several questions about this proposal.
>
> To begin with a simple question: what the interface of std::bits will=20
> be? Same as std::bitset or same as std::integer, or a mix between=20
> both? Because I think an unsigned integer and a sequence of bits are=20
> not exactly "the same thing". For example, std::bitset does not=20
> provide arithmetic operators. Furthermore, how do you compare two=20
> std::bits? Lexicographically or by their integral representation? This=20
> is not the same thing... I agree that programmatically, std::bits and=20
> std::unsigned_integer are the same thing, but I think that their=20
> mathematical meaning is not the same.
>
> But my main concern is about performance for big numbers crunching. I=20
> think that one of the main drawbacks of GMP is performance when one=20
> already know the typical size of its integers (even if I've done some=20
> prime numbers calculation in the past, I am not an expert in this=20
> field, so I would like to have the point of view of more experienced=20
> user). So it would be great, at least I think, for performance purpose=20
> (and for integers we need performance) to have the possibility to=20
> choose between static or dynamic size.
>
> In fact, for an integer, I would have expected a generic class like=20
> std::basic_integer that will allow to specify:
> - the integral domain (signed/unsigned)
> - the size in bits if static size / the allocator if dynamic size
> - a conversion policy in order to handle proper conversions in=20
> arithmetic operations (for example what occurs when we add an integer=20
> with an Allocator1 and an integer with an Allocator2)
>
>
Hi,
as I understand the proposal, it address big integers, not fixed point=20
integers which are addressed by the Lawrence Crowl proposal. I suspect=20
that what you are locking for is fixed point integers with a bounded=20
representation. This kind of fixed point has not been addressed by=20
Lawrence proposal, but a lot of us work today with something similar.
Vicente
--=20
---=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--------------070009060207040003070102
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3DUTF-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">Le 12/03/14 12:19, Vincent Reverdy a
=C3=A9crit=C2=A0:<br>
</div>
<blockquote
cite=3D"mid:6a4bcbbb-1cf4-4fd8-8d41-154f6230f178@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">Hello.<br>
<br>
I have some questions about N3965:
<a class=3D"moz-txt-link-freetext" href=3D"http://www.open-std.org/=
jtc1/sc22/wg21/docs/papers/2014/n3965.html">http://www.open-std.org/jtc1/sc=
22/wg21/docs/papers/2014/n3965.html</a><br>
It is great without doubt, to standardize big integers. They
have been used for a long time with libraries like GMP and there
is a lot of existing practice and experience with them.<br>
However I have several questions about this proposal.<br>
<br>
To begin with a simple question: what the interface of std::bits
will be? Same as <span style=3D"font-family: courier
new,monospace;">std::bitset</span> or same as <span
style=3D"font-family: courier new,monospace;">std::integer</span>=
,
or a mix between both? Because I think an unsigned integer and a
sequence of bits are not exactly "the same thing". For example,
<span style=3D"font-family: courier new,monospace;">std::bitset</sp=
an>
does not provide arithmetic operators. Furthermore, how do you
compare two <span style=3D"font-family: courier new,monospace;">std=
::bits</span>?
Lexicographically or by their integral representation? This is
not the same thing... I agree that programmatically, <span
style=3D"font-family: courier new,monospace;">std::bits</span>
and <span style=3D"font-family: courier new,monospace;">std::unsign=
ed_integer</span>
are the same thing, but I think that their mathematical meaning
is not the same.<br>
<br>
But my main concern is about performance for big numbers
crunching. I think that one of the main drawbacks of GMP is
performance when one already know the typical size of its
integers (even if I've done some prime numbers calculation in
the past, I am not an expert in this field, so I would like to
have the point of view of more experienced user). So it would be
great, at least I think, for performance purpose (and for
integers we need performance) to have the possibility to choose
between static or dynamic size.<br>
<br>
In fact, for an integer, I would have expected a generic class
like <span style=3D"font-family: courier new,monospace;">std::basic=
_integer</span>
that will allow to specify:<br>
- the integral domain (signed/unsigned)<br>
- the size in bits if static size / the allocator if dynamic
size<br>
- a conversion policy in order to handle proper conversions in
arithmetic operations (for example what occurs when we add an
integer with an Allocator1 and an integer with an Allocator2)<br>
<br>
<br>
</div>
</blockquote>
Hi, <br>
<br>
as I understand the proposal, it address big integers, not fixed
point integers which are addressed by the Lawrence Crowl proposal. I
suspect that what you are locking for is fixed point integers with a
bounded representation. This kind of fixed point has not been
addressed by Lawrence proposal, but a lot of us work today with
something similar.<br>
<br>
Vicente<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--------------070009060207040003070102--
.
Author: Vincent Reverdy <vince.rev@gmail.com>
Date: Wed, 12 Mar 2014 13:02:43 -0700 (PDT)
Raw View
------=_Part_1192_18237713.1394654563596
Content-Type: text/plain; charset=UTF-8
Do you have a link to the Lawrence Crowl proposal? I've not found it in the
2014 or 2013 mailing (but maybe I was not searching with the right
keywords...).
I'm looking for a way to specify the size at compile-time like a
static_integer<1024> for 1024 bits to have the guarantee to get the best
possible performance for some heavy number theoretic operations...
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_1192_18237713.1394654563596
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Do you have a link to the Lawrence Crowl proposal? I've no=
t found it in the 2014 or 2013 mailing (but maybe I was not searching with =
the right keywords...).<br><div dir=3D"ltr">I'm looking for a way to specif=
y the size at compile-time like a static_integer<1024> for 1024 bits =
to have the guarantee to get the best possible performance for some heavy n=
umber theoretic operations...<br> <br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1192_18237713.1394654563596--
.
Author: Alexander Zaitsev <zamazan4ik@gmail.com>
Date: Fri, 2 Feb 2018 11:31:25 -0800 (PST)
Raw View
------=_Part_770_756270910.1517599885570
Content-Type: multipart/alternative;
boundary="----=_Part_771_1671723309.1517599885570"
------=_Part_771_1671723309.1517599885570
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
=D1=81=D1=80=D0=B5=D0=B4=D0=B0, 12 =D0=BC=D0=B0=D1=80=D1=82=D0=B0 2014 =D0=
=B3., 14:19:25 UTC+3 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=
=D0=B5=D0=BB=D1=8C Vincent Reverdy=20
=D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:
>
> Hello.
>
> I have some questions about N3965:=20
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3965.html
> It is great without doubt, to standardize big integers. They have been=20
> used for a long time with libraries like GMP and there is a lot of existi=
ng=20
> practice and experience with them.
> However I have several questions about this proposal.
>
> To begin with a simple question: what the interface of std::bits will be?=
=20
> Same as std::bitset or same as std::integer, or a mix between both?=20
> Because I think an unsigned integer and a sequence of bits are not exactl=
y=20
> "the same thing". For example, std::bitset does not provide arithmetic=20
> operators. Furthermore, how do you compare two std::bits?=20
> Lexicographically or by their integral representation? This is not the sa=
me=20
> thing... I agree that programmatically, std::bits and=20
> std::unsigned_integer are the same thing, but I think that their=20
> mathematical meaning is not the same.
>
> But my main concern is about performance for big numbers crunching. I=20
> think that one of the main drawbacks of GMP is performance when one alrea=
dy=20
> know the typical size of its integers (even if I've done some prime numbe=
rs=20
> calculation in the past, I am not an expert in this field, so I would lik=
e=20
> to have the point of view of more experienced user). So it would be great=
,=20
> at least I think, for performance purpose (and for integers we need=20
> performance) to have the possibility to choose between static or dynamic=
=20
> size.
>
> In fact, for an integer, I would have expected a generic class like=20
> std::basic_integer that will allow to specify:
> - the integral domain (signed/unsigned)
> - the size in bits if static size / the allocator if dynamic size
> - a conversion policy in order to handle proper conversions in arithmetic=
=20
> operations (for example what occurs when we add an integer with an=20
> Allocator1 and an integer with an Allocator2)
>
> with predefined aliases for:
> - dynamic signed integer
> - dynamic unsigned integer
> - static signed integer
> - static unsigned integer
>
> But I wonder if it is a very personnal feeling or if some people have the=
=20
> same kind of opinion about that.
>
> Thank you very much for your feedback and clarifications.
>
> Vincent
>
>
Sorry for necroposting, but what is the status of the proposal?
=20
--=20
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 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-proposals/9230959b-a00a-4103-a697-c73389cedb0a%40isocpp.or=
g.
------=_Part_771_1671723309.1517599885570
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">=D1=81=D1=80=D0=B5=D0=B4=D0=B0, 12 =D0=BC=D0=B0=D1=80=D1=
=82=D0=B0 2014 =D0=B3., 14:19:25 UTC+3 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=
=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Vincent Reverdy =D0=BD=D0=B0=D0=BF=D0=
=B8=D1=81=D0=B0=D0=BB:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">Hello.<br><br>I have some questions about N3965: <a href=3D"http:/=
/www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3965.html" target=3D"_bl=
ank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google.com=
/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpaper=
s%2F2014%2Fn3965.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGXPQvbkqRB5Uw=
CgIuHDTAv8ds-Sw';return true;" onclick=3D"this.href=3D'http://www.g=
oogle.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdoc=
s%2Fpapers%2F2014%2Fn3965.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGXPQ=
vbkqRB5UwCgIuHDTAv8ds-Sw';return true;">http://www.open-std.org/jtc1/<w=
br>sc22/wg21/docs/papers/2014/<wbr>n3965.html</a><br>It is great without do=
ubt, to standardize big integers. They have been used for a long time with =
libraries like GMP and there is a lot of existing practice and experience w=
ith them.<br>However I have several questions about this proposal.<br><br>T=
o begin with a simple question: what the interface of std::bits will be? Sa=
me as <span style=3D"font-family:courier new,monospace">std::bitset</span> =
or same as <span style=3D"font-family:courier new,monospace">std::integer</=
span>, or a mix between both? Because I think an unsigned integer and a seq=
uence of bits are not exactly "the same thing". For example, <spa=
n style=3D"font-family:courier new,monospace">std::bitset</span> does not p=
rovide arithmetic operators. Furthermore, how do you compare two <span styl=
e=3D"font-family:courier new,monospace">std::bits</span>? Lexicographically=
or by their integral representation? This is not the same thing... I agree=
that programmatically, <span style=3D"font-family:courier new,monospace">s=
td::bits</span> and <span style=3D"font-family:courier new,monospace">std::=
unsigned_integer</span> are the same thing, but I think that their mathemat=
ical meaning is not the same.<br><br>But my main concern is about performan=
ce for big numbers crunching. I think that one of the main drawbacks of GMP=
is performance when one already know the typical size of its integers (eve=
n if I've done some prime numbers calculation in the past, I am not an =
expert in this field, so I would like to have the point of view of more exp=
erienced user). So it would be great, at least I think, for performance pur=
pose (and for integers we need performance) to have the possibility to choo=
se between static or dynamic size.<br><br>In fact, for an integer, I would =
have expected a generic class like <span style=3D"font-family:courier new,m=
onospace">std::basic_integer</span> that will allow to specify:<br>- the in=
tegral domain (signed/unsigned)<br>- the size in bits if static size / the =
allocator if dynamic size<br>- a conversion policy in order to handle prope=
r conversions in arithmetic operations (for example what occurs when we add=
an integer with an Allocator1 and an integer with an Allocator2)<br><br>wi=
th predefined aliases for:<br>- dynamic signed integer<br>- dynamic unsigne=
d integer<br>- static signed integer<br>- static unsigned integer<br><br>Bu=
t I wonder if it is a very personnal feeling or if some people have the sam=
e kind of opinion about that.<br><br>Thank you very much for your feedback =
and clarifications.<br><br>Vincent<br><br></div></blockquote><div><br></div=
><div><br></div><div>Sorry for necroposting, but what is the status of the =
proposal?</div><div><br></div><div>=C2=A0</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/9230959b-a00a-4103-a697-c73389cedb0a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9230959b-a00a-4103-a697-c73389cedb0a=
%40isocpp.org</a>.<br />
------=_Part_771_1671723309.1517599885570--
------=_Part_770_756270910.1517599885570--
.
Author: Erich Keane <erich.keane@verizon.net>
Date: Fri, 2 Feb 2018 14:28:26 -0800 (PST)
Raw View
------=_Part_9200_1080697401.1517610506186
Content-Type: multipart/alternative;
boundary="----=_Part_9201_830906576.1517610506187"
------=_Part_9201_830906576.1517610506187
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Looks like it was rev'ed once more here=20
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4038.html with a=
=20
large amount of defects to fix, and was discussed in SG6 in the Lenexa in=
=20
2015. There was a couple of issues brought up (SG6's minutes aren't very=
=20
detailed), but no further activity. You may wish to contact the author to=
=20
see what has since happened. =20
On Friday, February 2, 2018 at 11:31:25 AM UTC-8, Alexander Zaitsev wrote:
>
> =D1=81=D1=80=D0=B5=D0=B4=D0=B0, 12 =D0=BC=D0=B0=D1=80=D1=82=D0=B0 2014 =
=D0=B3., 14:19:25 UTC+3 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=
=82=D0=B5=D0=BB=D1=8C Vincent Reverdy=20
> =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:
>>
>> Hello.
>>
>> I have some questions about N3965:=20
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3965.html
>> It is great without doubt, to standardize big integers. They have been=
=20
>> used for a long time with libraries like GMP and there is a lot of exist=
ing=20
>> practice and experience with them.
>> However I have several questions about this proposal.
>>
>> To begin with a simple question: what the interface of std::bits will be=
?=20
>> Same as std::bitset or same as std::integer, or a mix between both?=20
>> Because I think an unsigned integer and a sequence of bits are not exact=
ly=20
>> "the same thing". For example, std::bitset does not provide arithmetic=
=20
>> operators. Furthermore, how do you compare two std::bits?=20
>> Lexicographically or by their integral representation? This is not the s=
ame=20
>> thing... I agree that programmatically, std::bits and=20
>> std::unsigned_integer are the same thing, but I think that their=20
>> mathematical meaning is not the same.
>>
>> But my main concern is about performance for big numbers crunching. I=20
>> think that one of the main drawbacks of GMP is performance when one alre=
ady=20
>> know the typical size of its integers (even if I've done some prime numb=
ers=20
>> calculation in the past, I am not an expert in this field, so I would li=
ke=20
>> to have the point of view of more experienced user). So it would be grea=
t,=20
>> at least I think, for performance purpose (and for integers we need=20
>> performance) to have the possibility to choose between static or dynamic=
=20
>> size.
>>
>> In fact, for an integer, I would have expected a generic class like=20
>> std::basic_integer that will allow to specify:
>> - the integral domain (signed/unsigned)
>> - the size in bits if static size / the allocator if dynamic size
>> - a conversion policy in order to handle proper conversions in arithmeti=
c=20
>> operations (for example what occurs when we add an integer with an=20
>> Allocator1 and an integer with an Allocator2)
>>
>> with predefined aliases for:
>> - dynamic signed integer
>> - dynamic unsigned integer
>> - static signed integer
>> - static unsigned integer
>>
>> But I wonder if it is a very personnal feeling or if some people have th=
e=20
>> same kind of opinion about that.
>>
>> Thank you very much for your feedback and clarifications.
>>
>> Vincent
>>
>>
>
> Sorry for necroposting, but what is the status of the proposal?
>
> =20
>
--=20
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 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-proposals/7aa4d72f-a06f-4faa-a153-604f4f15242d%40isocpp.or=
g.
------=_Part_9201_830906576.1517610506187
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Looks like it was rev'ed once more here http://www.ope=
n-std.org/jtc1/sc22/wg21/docs/papers/2014/n4038.html with a large amount of=
defects to fix, and was discussed in SG6 in the Lenexa in 2015.=C2=A0 Ther=
e was a couple of issues brought up (SG6's minutes aren't very deta=
iled), but no further activity.=C2=A0=C2=A0 You may wish to contact the aut=
hor to see what has since happened.=C2=A0 <br><br>On Friday, February 2, 20=
18 at 11:31:25 AM UTC-8, Alexander Zaitsev wrote:<blockquote class=3D"gmail=
_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;p=
adding-left: 1ex;"><div dir=3D"ltr">=D1=81=D1=80=D0=B5=D0=B4=D0=B0, 12 =D0=
=BC=D0=B0=D1=80=D1=82=D0=B0 2014 =D0=B3., 14:19:25 UTC+3 =D0=BF=D0=BE=D0=BB=
=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Vincent Reverdy =D0=
=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:<blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div dir=3D"ltr">Hello.<br><br>I have some questions about N3965: <a h=
ref=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3965.html" =
rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=3D'http://w=
ww.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2=
Fdocs%2Fpapers%2F2014%2Fn3965.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCN=
GXPQvbkqRB5UwCgIuHDTAv8ds-Sw';return true;" onclick=3D"this.href=3D'=
;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22=
%2Fwg21%2Fdocs%2Fpapers%2F2014%2Fn3965.html\x26sa\x3dD\x26sntz\x3d1\x26usg\=
x3dAFQjCNGXPQvbkqRB5UwCgIuHDTAv8ds-Sw';return true;">http://www.open-st=
d.org/jtc1/<wbr>sc22/wg21/docs/papers/2014/<wbr>n3965.html</a><br>It is gre=
at without doubt, to standardize big integers. They have been used for a lo=
ng time with libraries like GMP and there is a lot of existing practice and=
experience with them.<br>However I have several questions about this propo=
sal.<br><br>To begin with a simple question: what the interface of std::bit=
s will be? Same as <span style=3D"font-family:courier new,monospace">std::b=
itset</span> or same as <span style=3D"font-family:courier new,monospace">s=
td::integer</span>, or a mix between both? Because I think an unsigned inte=
ger and a sequence of bits are not exactly "the same thing". For =
example, <span style=3D"font-family:courier new,monospace">std::bitset</spa=
n> does not provide arithmetic operators. Furthermore, how do you compare t=
wo <span style=3D"font-family:courier new,monospace">std::bits</span>? Lexi=
cographically or by their integral representation? This is not the same thi=
ng... I agree that programmatically, <span style=3D"font-family:courier new=
,monospace">std::bits</span> and <span style=3D"font-family:courier new,mon=
ospace">std::unsigned_integer</span> are the same thing, but I think that t=
heir mathematical meaning is not the same.<br><br>But my main concern is ab=
out performance for big numbers crunching. I think that one of the main dra=
wbacks of GMP is performance when one already know the typical size of its =
integers (even if I've done some prime numbers calculation in the past,=
I am not an expert in this field, so I would like to have the point of vie=
w of more experienced user). So it would be great, at least I think, for pe=
rformance purpose (and for integers we need performance) to have the possib=
ility to choose between static or dynamic size.<br><br>In fact, for an inte=
ger, I would have expected a generic class like <span style=3D"font-family:=
courier new,monospace">std::basic_integer</span> that will allow to specify=
:<br>- the integral domain (signed/unsigned)<br>- the size in bits if stati=
c size / the allocator if dynamic size<br>- a conversion policy in order to=
handle proper conversions in arithmetic operations (for example what occur=
s when we add an integer with an Allocator1 and an integer with an Allocato=
r2)<br><br>with predefined aliases for:<br>- dynamic signed integer<br>- dy=
namic unsigned integer<br>- static signed integer<br>- static unsigned inte=
ger<br><br>But I wonder if it is a very personnal feeling or if some people=
have the same kind of opinion about that.<br><br>Thank you very much for y=
our feedback and clarifications.<br><br>Vincent<br><br></div></blockquote><=
div><br></div><div><br></div><div>Sorry for necroposting, but what is the s=
tatus of the proposal?</div><div><br></div><div>=C2=A0</div></div></blockqu=
ote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/7aa4d72f-a06f-4faa-a153-604f4f15242d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7aa4d72f-a06f-4faa-a153-604f4f15242d=
%40isocpp.org</a>.<br />
------=_Part_9201_830906576.1517610506187--
------=_Part_9200_1080697401.1517610506186--
.
Author: John McFarlane <john@mcfarlane.name>
Date: Sun, 04 Feb 2018 04:52:49 +0000
Raw View
--089e0826a3f442ba2505645bb817
Content-Type: text/plain; charset="UTF-8"
On Fri, Feb 2, 2018 at 2:28 PM Erich Keane <erich.keane@verizon.net> wrote:
> Looks like it was rev'ed once more here
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4038.html with a
> large amount of defects to fix, and was discussed in SG6 in the Lenexa in
> 2015. There was a couple of issues brought up (SG6's minutes aren't very
> detailed), but no further activity. You may wish to contact the author to
> see what has since happened.
>
It is mentioned later in 2015 in P0101 [1] and bounded integers are
mentioned separately. They would seem to me to be different types in a
similar way that `vector` and `array` are different.
1.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0101r0.html#UnboundInteger
--
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/CABPJVnTLwUB2-js%2BYp6g%3DgmawVWQiPCnLOGVrPTGQFr4R%3D53vw%40mail.gmail.com.
--089e0826a3f442ba2505645bb817
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Fri, Feb 2,=
2018 at 2:28 PM Erich Keane <<a href=3D"mailto:erich.keane@verizon.net"=
>erich.keane@verizon.net</a>> wrote:<br></div><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div dir=3D"ltr">Looks like it was rev'ed once more here <a href=
=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4038.html" tar=
get=3D"_blank">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n403=
8.html</a> with a large amount of defects to fix, and was discussed in SG6 =
in the Lenexa in 2015.=C2=A0 There was a couple of issues brought up (SG6&#=
39;s minutes aren't very detailed), but no further activity.=C2=A0=C2=
=A0 You may wish to contact the author to see what has since happened.=C2=
=A0 <br></div></blockquote><div><br></div><div>It is mentioned later in 201=
5 in P0101 [1] and bounded integers are mentioned separately. They would se=
em to me to be different types in a similar way that `vector`=20
and `array`=20
are different.<br><br>1. <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/=
docs/papers/2015/p0101r0.html#UnboundInteger">http://www.open-std.org/jtc1/=
sc22/wg21/docs/papers/2015/p0101r0.html#UnboundInteger</a></div><br></div><=
/div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CABPJVnTLwUB2-js%2BYp6g%3DgmawVWQiPCn=
LOGVrPTGQFr4R%3D53vw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CABPJVnTLwU=
B2-js%2BYp6g%3DgmawVWQiPCnLOGVrPTGQFr4R%3D53vw%40mail.gmail.com</a>.<br />
--089e0826a3f442ba2505645bb817--
.
Author: Alexander Zaitsev <zamazan4ik@gmail.com>
Date: Tue, 6 Feb 2018 13:44:55 -0800 (PST)
Raw View
------=_Part_5761_90192015.1517953495523
Content-Type: multipart/alternative;
boundary="----=_Part_5762_1410012787.1517953495523"
------=_Part_5762_1410012787.1517953495523
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
So after couple of tries i didn't get any response from the author, Pete=20
Becker. So i decided to revive this proposal and adopt it to modern C++. I=
=20
suggest:
- Remove from this paper=20
class bits
=20
. Reason: there is proposal about adavnaced set of classes for working=
=20
with=20
bits: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0237r9.pd=
f .=20
Later, if proposal with bits stuff will be accepted into C++ standard, w=
e=20
can add interatction with bits classes to unbounded integers with anothe=
r=20
paper.
- (difficult question) Instead of writing new integer_data_proxy class=
=20
we can use simply=20
template <class Allocator> using integer_data_proxy =3D std::vector<
unspecified, Allocator>
But i am not sure, is it good way or not. Should be discussed.
- Add more methods with rvalue support (see Open Issues #5 from Joe=20
Gottman)
- Change std::hash specialization
- In this proposal e.g. for 'pow' function we have two versions: as=20
function and as method. For what we should support pow function as metho=
d?=20
Performance reasons?
More ideas? You are welcome.
=D1=81=D1=80=D0=B5=D0=B4=D0=B0, 12 =D0=BC=D0=B0=D1=80=D1=82=D0=B0 2014 =D0=
=B3., 14:19:25 UTC+3 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=
=D0=B5=D0=BB=D1=8C Vincent Reverdy=20
=D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:
>
> Hello.
>
> I have some questions about N3965:=20
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3965.html
> It is great without doubt, to standardize big integers. They have been=20
> used for a long time with libraries like GMP and there is a lot of existi=
ng=20
> practice and experience with them.
> However I have several questions about this proposal.
>
> To begin with a simple question: what the interface of std::bits will be?=
=20
> Same as std::bitset or same as std::integer, or a mix between both?=20
> Because I think an unsigned integer and a sequence of bits are not exactl=
y=20
> "the same thing". For example, std::bitset does not provide arithmetic=20
> operators. Furthermore, how do you compare two std::bits?=20
> Lexicographically or by their integral representation? This is not the sa=
me=20
> thing... I agree that programmatically, std::bits and=20
> std::unsigned_integer are the same thing, but I think that their=20
> mathematical meaning is not the same.
>
> But my main concern is about performance for big numbers crunching. I=20
> think that one of the main drawbacks of GMP is performance when one alrea=
dy=20
> know the typical size of its integers (even if I've done some prime numbe=
rs=20
> calculation in the past, I am not an expert in this field, so I would lik=
e=20
> to have the point of view of more experienced user). So it would be great=
,=20
> at least I think, for performance purpose (and for integers we need=20
> performance) to have the possibility to choose between static or dynamic=
=20
> size.
>
> In fact, for an integer, I would have expected a generic class like=20
> std::basic_integer that will allow to specify:
> - the integral domain (signed/unsigned)
> - the size in bits if static size / the allocator if dynamic size
> - a conversion policy in order to handle proper conversions in arithmetic=
=20
> operations (for example what occurs when we add an integer with an=20
> Allocator1 and an integer with an Allocator2)
>
> with predefined aliases for:
> - dynamic signed integer
> - dynamic unsigned integer
> - static signed integer
> - static unsigned integer
>
> But I wonder if it is a very personnal feeling or if some people have the=
=20
> same kind of opinion about that.
>
> Thank you very much for your feedback and clarifications.
>
> Vincent
>
>
--=20
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 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-proposals/7cef921a-cb9f-43db-b39b-10585f658845%40isocpp.or=
g.
------=_Part_5762_1410012787.1517953495523
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">So after couple of tries i didn't get any response fro=
m the author, Pete Becker. So i decided to revive this proposal and adopt i=
t to modern C++. I suggest:<div><ul><li>Remove from this paper <div class=
=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border-colo=
r: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wrap: b=
reak-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span=
style=3D"color: #008;" class=3D"styled-by-prettify">class</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> bits</span></div></code></=
div><br>. Reason: there is proposal about adavnaced set of classes for work=
ing with bits:=C2=A0http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017=
/p0237r9.pdf . Later, if proposal with bits stuff will be accepted into C++=
standard, we can add interatction with bits classes to unbounded integers =
with another paper.</li><li>(difficult question) Instead of writing new int=
eger_data_proxy class we can use simply <div class=3D"prettyprint" style=3D=
"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); bo=
rder-style: solid; border-width: 1px; word-wrap: break-word;"><code class=
=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;"=
class=3D"styled-by-prettify">template</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify"><</span><span style=3D"color: #008;" class=3D"styled-=
by-prettify">class</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">A=
llocator</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&g=
t;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span>=
<span style=3D"color: #008;" class=3D"styled-by-prettify">using</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify"> integer_data_proxy </=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> std</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify">vector</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify"><</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify">unspecified</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"style=
d-by-prettify">Allocator</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">></span></div></code></div>But i am not sure, is it good w=
ay or not. Should be discussed.</li><li>Add more methods with rvalue suppor=
t (see Open Issues #5 from Joe Gottman)</li><li>Change std::hash specializa=
tion</li><li>In this proposal e.g. for 'pow' function we have two v=
ersions: as function and as method. For what we should support pow function=
as method? Performance reasons?</li></ul><div><br></div><div>More ideas? Y=
ou are welcome.</div><br>=D1=81=D1=80=D0=B5=D0=B4=D0=B0, 12 =D0=BC=D0=B0=D1=
=80=D1=82=D0=B0 2014 =D0=B3., 14:19:25 UTC+3 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=
=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Vincent Reverdy =D0=BD=D0=B0=D0=
=BF=D0=B8=D1=81=D0=B0=D0=BB:<blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><d=
iv dir=3D"ltr">Hello.<br><br>I have some questions about N3965: <a href=3D"=
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3965.html" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.goo=
gle.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%=
2Fpapers%2F2014%2Fn3965.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGXPQvb=
kqRB5UwCgIuHDTAv8ds-Sw';return true;" onclick=3D"this.href=3D'http:=
//www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg2=
1%2Fdocs%2Fpapers%2F2014%2Fn3965.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQ=
jCNGXPQvbkqRB5UwCgIuHDTAv8ds-Sw';return true;">http://www.open-std.org/=
jtc1/<wbr>sc22/wg21/docs/papers/2014/<wbr>n3965.html</a><br>It is great wit=
hout doubt, to standardize big integers. They have been used for a long tim=
e with libraries like GMP and there is a lot of existing practice and exper=
ience with them.<br>However I have several questions about this proposal.<b=
r><br>To begin with a simple question: what the interface of std::bits will=
be? Same as <span style=3D"font-family:courier new,monospace">std::bitset<=
/span> or same as <span style=3D"font-family:courier new,monospace">std::in=
teger</span>, or a mix between both? Because I think an unsigned integer an=
d a sequence of bits are not exactly "the same thing". For exampl=
e, <span style=3D"font-family:courier new,monospace">std::bitset</span> doe=
s not provide arithmetic operators. Furthermore, how do you compare two <sp=
an style=3D"font-family:courier new,monospace">std::bits</span>? Lexicograp=
hically or by their integral representation? This is not the same thing... =
I agree that programmatically, <span style=3D"font-family:courier new,monos=
pace">std::bits</span> and <span style=3D"font-family:courier new,monospace=
">std::unsigned_integer</span> are the same thing, but I think that their m=
athematical meaning is not the same.<br><br>But my main concern is about pe=
rformance for big numbers crunching. I think that one of the main drawbacks=
of GMP is performance when one already know the typical size of its intege=
rs (even if I've done some prime numbers calculation in the past, I am =
not an expert in this field, so I would like to have the point of view of m=
ore experienced user). So it would be great, at least I think, for performa=
nce purpose (and for integers we need performance) to have the possibility =
to choose between static or dynamic size.<br><br>In fact, for an integer, I=
would have expected a generic class like <span style=3D"font-family:courie=
r new,monospace">std::basic_integer</span> that will allow to specify:<br>-=
the integral domain (signed/unsigned)<br>- the size in bits if static size=
/ the allocator if dynamic size<br>- a conversion policy in order to handl=
e proper conversions in arithmetic operations (for example what occurs when=
we add an integer with an Allocator1 and an integer with an Allocator2)<br=
><br>with predefined aliases for:<br>- dynamic signed integer<br>- dynamic =
unsigned integer<br>- static signed integer<br>- static unsigned integer<br=
><br>But I wonder if it is a very personnal feeling or if some people have =
the same kind of opinion about that.<br><br>Thank you very much for your fe=
edback and clarifications.<br><br>Vincent<br><br></div></blockquote></div><=
/div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/7cef921a-cb9f-43db-b39b-10585f658845%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7cef921a-cb9f-43db-b39b-10585f658845=
%40isocpp.org</a>.<br />
------=_Part_5762_1410012787.1517953495523--
------=_Part_5761_90192015.1517953495523--
.