Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #122790 > unrolled thread

Is there a current best library for large integers?

Back to article view | Back to comp.lang.c++

Contents

  Is there a current best library for large integers? Vir Campestris <vir.campestris@invalid.invalid> - 2025-09-29 21:08 +0100
    Re: Is there a current best library for large integers? olcott <polcott333@gmail.com> - 2025-09-29 15:40 -0500
      Re: Is there a current best library for large integers? Bonita Montero <Bonita.Montero@gmail.com> - 2025-10-07 18:24 +0200
        Re: Is there a current best library for large integers? scott@slp53.sl.home (Scott Lurndal) - 2025-10-07 17:56 +0000
          Re: Is there a current best library for large integers? Bonita Montero <Bonita.Montero@gmail.com> - 2025-10-08 04:38 +0200
            Re: Is there a current best library for large integers? scott@slp53.sl.home (Scott Lurndal) - 2025-10-08 14:02 +0000
    Re: Is there a current best library for large integers? olcott <polcott333@gmail.com> - 2025-09-29 15:45 -0500
    Re: Is there a current best library for large integers? Barry Schwarz <schwarzb@delq.com> - 2025-09-29 14:19 -0700
    Re: Is there a current best library for large integers? Michael S <already5chosen@yahoo.com> - 2025-09-30 01:03 +0300
      Re: Is there a current best library for large integers? David Brown <david.brown@hesbynett.no> - 2025-09-30 09:17 +0200
        Re: Is there a current best library for large integers? Michael S <already5chosen@yahoo.com> - 2025-09-30 14:02 +0300
        Re: Is there a current best library for large integers? Lynn McGuire <lynnmcguire5@gmail.com> - 2025-10-03 15:41 -0500
      Re: Is there a current best library for large integers? Vir Campestris <vir.campestris@invalid.invalid> - 2025-10-03 17:05 +0100
        Re: Is there a current best library for large integers? Ralf Goertz <me@myprovider.invalid> - 2025-10-06 17:34 +0200
          Re: Is there a current best library for large integers? Paavo Helde <eesnimi@osa.pri.ee> - 2025-10-07 10:44 +0300
            Re: Is there a current best library for large integers? Ralf Goertz <me@myprovider.invalid> - 2025-10-07 10:51 +0200
    Re: Is there a current best library for large integers? Michael S <already5chosen@yahoo.com> - 2025-09-30 14:21 +0300

#122790 — Is there a current best library for large integers?

I could knock something up - all I need to do is total a ****** lot of 
small numbers accurately, but the result is more than 64 bits.

Andy
-- 
Do not listen to rumour, but, if you do, do not believe it.
Ghandi.

[toc] | [next] | [standalone]

#122791

On 9/29/2025 3:08 PM, Vir Campestris wrote:
> I could knock something up - all I need to do is total a ****** lot of 
> small numbers accurately, but the result is more than 64 bits.
> 
> Andy

Its not too hard to do this using ASCII digits.
Then you have unlimited length.

-- 
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer

[toc] | [prev] | [next] | [standalone]

#122836

Am 29.09.2025 um 22:40 schrieb olcott:
> On 9/29/2025 3:08 PM, Vir Campestris wrote:
>> I could knock something up - all I need to do is total a ****** lot of 
>> small numbers accurately, but the result is more than 64 bits.
>>
>> Andy
> 
> Its not too hard to do this using ASCII digits.
> Then you have unlimited length.

And how do you do the math with that ?

[toc] | [prev] | [next] | [standalone]

#122837

Bonita Montero <Bonita.Montero@gmail.com> writes:
>Am 29.09.2025 um 22:40 schrieb olcott:
>> On 9/29/2025 3:08 PM, Vir Campestris wrote:
>>> I could knock something up - all I need to do is total a ****** lot of 
>>> small numbers accurately, but the result is more than 64 bits.
>>>
>>> Andy
>> 
>> Its not too hard to do this using ASCII digits.
>> Then you have unlimited length.
>
>And how do you do the math with that ?

  mpz_init_set_str()

[toc] | [prev] | [next] | [standalone]

#122838

Am 07.10.2025 um 19:56 schrieb Scott Lurndal:
> Bonita Montero <Bonita.Montero@gmail.com> writes:
>> Am 29.09.2025 um 22:40 schrieb olcott:
>>> On 9/29/2025 3:08 PM, Vir Campestris wrote:
>>>> I could knock something up - all I need to do is total a ****** lot of
>>>> small numbers accurately, but the result is more than 64 bits.
>>>>
>>>> Andy
>>>
>>> Its not too hard to do this using ASCII digits.
>>> Then you have unlimited length.
>>
>> And how do you do the math with that ?
> 
>    mpz_init_set_str()

The math isn't done with ASCII for that.

[toc] | [prev] | [next] | [standalone]

#122839

Bonita Montero <Bonita.Montero@gmail.com> writes:
>Am 07.10.2025 um 19:56 schrieb Scott Lurndal:
>> Bonita Montero <Bonita.Montero@gmail.com> writes:
>>> Am 29.09.2025 um 22:40 schrieb olcott:
>>>> On 9/29/2025 3:08 PM, Vir Campestris wrote:
>>>>> I could knock something up - all I need to do is total a ****** lot of
>>>>> small numbers accurately, but the result is more than 64 bits.
>>>>>
>>>>> Andy
>>>>
>>>> Its not too hard to do this using ASCII digits.
>>>> Then you have unlimited length.
>>>
>>> And how do you do the math with that ?
>> 
>>    mpz_init_set_str()
>
>The math isn't done with ASCII for that.

So what?  The input is ASCII and the output can
be ASCII (or EBCDIC or whatever) and the length
of the operands is limited only by the size of
the available address space.

There were systems in in the past that did the
math directly on ASCII (or EBCDIC) data, such
as the Burroughs medium systems.  There, the processor
simply ignored the zone digit.  Operands could
range from 1 to 100 digits.

[toc] | [prev] | [next] | [standalone]

#122792

On 9/29/2025 3:08 PM, Vir Campestris wrote:
> I could knock something up - all I need to do is total a ****** lot of 
> small numbers accurately, but the result is more than 64 bits.
> 
> Andy

GMP is a free library for arbitrary precision arithmetic, operating on 
signed integers, rational numbers, and floating-point numbers. There is 
no practical limit to the precision except the ones implied by the 
available memory in the machine GMP runs on. GMP has a rich set of 
functions, and the functions have a regular interface.

http://gmplib.org/

-- 
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer

[toc] | [prev] | [next] | [standalone]

#122793

On Mon, 29 Sep 2025 21:08:09 +0100, Vir Campestris
<vir.campestris@invalid.invalid> wrote:

>I could knock something up - all I need to do is total a ****** lot of 
>small numbers accurately, but the result is more than 64 bits.
>
>Andy

I like the one at https://mattmccutchen.net/bigint/.

-- 
Remove del for email

[toc] | [prev] | [next] | [standalone]

#122794

On Mon, 29 Sep 2025 21:08:09 +0100
Vir Campestris <vir.campestris@invalid.invalid> wrote:

> I could knock something up - all I need to do is total a ****** lot
> of small numbers accurately, but the result is more than 64 bits.
> 
> Andy

If you neeed just a little more than 64 bit then use 128-bit integers.
For decades gcc and clang feature a non-standard type __int128.

Or switch to better languge. Then you can use standard type
_BitInt(128). Or _BitInt(256). Or _BitInt(0x8000).

As a general rule, C is a decent improvement on its successor and that
is just one example.

[toc] | [prev] | [next] | [standalone]

#122796

On 30/09/2025 00:03, Michael S wrote:
> On Mon, 29 Sep 2025 21:08:09 +0100
> Vir Campestris <vir.campestris@invalid.invalid> wrote:
> 
>> I could knock something up - all I need to do is total a ****** lot
>> of small numbers accurately, but the result is more than 64 bits.
>>
>> Andy
> 
> If you neeed just a little more than 64 bit then use 128-bit integers.
> For decades gcc and clang feature a non-standard type __int128.

Yes, that should be the easiest way - as long as the target has native 
64-bit support.  For 32-bit (or smaller) targets, gcc does not have 
__int128.

A simple "Int128" class with support for basic arithmetic should be 
quick to write, however - especially if you don't need division.

> 
> Or switch to better languge. Then you can use standard type
> _BitInt(128). Or _BitInt(256). Or _BitInt(0x8000).
> 
> As a general rule, C is a decent improvement on its successor and that
> is just one example.
> 

_BitInt is likely coming to C++ too, though the details are not in place 
yet.  I'd guess any C and C++ compiler that supports _BitInt in C23 will 
also accept it as a non-standard extension in C++.

[toc] | [prev] | [next] | [standalone]

#122797

On Tue, 30 Sep 2025 09:17:09 +0200
David Brown <david.brown@hesbynett.no> wrote:

> 
> _BitInt is likely coming to C++ too, though the details are not in
> place yet.  I'd guess any C and C++ compiler that supports _BitInt in
> C23 will also accept it as a non-standard extension in C++.
> 

Both gcc and clang already supports _BitInt in C.
clang, indeed, supports it as a non-standard extension in C++, but then
again, clang people invented it and had it as a non-standard extension
in C even before it was standardized.
OTOH, gcc does *not* accept it in C++.

[toc] | [prev] | [next] | [standalone]

#122810

On 9/30/2025 2:17 AM, David Brown wrote:
> On 30/09/2025 00:03, Michael S wrote:
>> On Mon, 29 Sep 2025 21:08:09 +0100
>> Vir Campestris <vir.campestris@invalid.invalid> wrote:
>>
>>> I could knock something up - all I need to do is total a ****** lot
>>> of small numbers accurately, but the result is more than 64 bits.
>>>
>>> Andy
>>
>> If you neeed just a little more than 64 bit then use 128-bit integers.
>> For decades gcc and clang feature a non-standard type __int128.
> 
> Yes, that should be the easiest way - as long as the target has native 
> 64-bit support.  For 32-bit (or smaller) targets, gcc does not have 
> __int128.
> 
> A simple "Int128" class with support for basic arithmetic should be 
> quick to write, however - especially if you don't need division.
> 
>>
>> Or switch to better languge. Then you can use standard type
>> _BitInt(128). Or _BitInt(256). Or _BitInt(0x8000).
>>
>> As a general rule, C is a decent improvement on its successor and that
>> is just one example.
>>
> 
> _BitInt is likely coming to C++ too, though the details are not in place 
> yet.  I'd guess any C and C++ compiler that supports _BitInt in C23 will 
> also accept it as a non-standard extension in C++.

I use bigint in my C++ code.  I have used it for around 20 years now.

Lynn

[toc] | [prev] | [next] | [standalone]

#122809

On 29/09/2025 23:03, Michael S wrote:
> If you neeed just a little more than 64 bit then use 128-bit integers.
> For decades gcc and clang feature a non-standard type __int128.
I went away and thought about it. Then decided I'll never port this 
code, so I used __int128. I then found that you can't write it out, so I 
had to implement a string convert just to print the output!

Andy

-- 
Do not listen to rumour, but, if you do, do not believe it.
Ghandi.

[toc] | [prev] | [next] | [standalone]

#122833

Am Fri, 3 Oct 2025 17:05:38 +0100
schrieb Vir Campestris <vir.campestris@invalid.invalid>:

> On 29/09/2025 23:03, Michael S wrote:
>> If you neeed just a little more than 64 bit then use 128-bit
>> integers. For decades gcc and clang feature a non-standard type
>> __int128.  
> I went away and thought about it. Then decided I'll never port this 
> code, so I used __int128. I then found that you can't write it out, so
> I had to implement a string convert just to print the output!

Your post inspired me to do that myself (without having looked at the
implementations for the standard integer types or thought about that at
all ever before). This is what I came up with. It doesn't use
std::string to avoid overhead and respects the basefield and showbase
manipulators (but only them). What do you think?

#include <iostream>

std::ostream& operator<<(std::ostream& out, unsigned __int128 k) {
    if (k==0) return out<<'0'; //treat 0 specially
    unsigned __int128 base(10),
                      p(1); //cycles through powers of base
    auto  b=(out.flags() & std::ios::basefield);
    auto sb=(out.flags() & std::ios::showbase);
    if (b & std::ios::oct) {
        base=8;
        if (sb) out<<'0'; //octal prefix
    }
    if (b & std::ios::hex) {
        base=16;
        if (sb) out<<"0x"; //hex prefix
    }
    while (k/p>=base) { //find maximum power of base ≤ k
        p*=base;
    }
    while (p>0) {
        unsigned __int128 d=k/p; //coefficient for current power p of base 
        char c=static_cast<char>(d+'0'); //convert d to ASCII character 
        if (d>9) c+='a'-'9'-1; //shift characters bigger than
                               //'9' to lowercase letters for base 16
        out<<c;
        k-=d*p;
        p/=base;
    }
    return out;
}

std::ostream& operator<<(std::ostream& out, signed __int128 k) {
    if ((k<0) && (out.flags() & std::ios::dec)) {
        out<<'-'; //output a minus sign
        k*=-1; //change k to absolute value
    }
    return out<<static_cast<unsigned __int128>(k); //output the digits
}

[toc] | [prev] | [next] | [standalone]

#122834

On 10/6/2025 6:34 PM, Ralf Goertz wrote:
> Am Fri, 3 Oct 2025 17:05:38 +0100
> schrieb Vir Campestris <vir.campestris@invalid.invalid>:
> 
>> On 29/09/2025 23:03, Michael S wrote:
>>> If you neeed just a little more than 64 bit then use 128-bit
>>> integers. For decades gcc and clang feature a non-standard type
>>> __int128.
>> I went away and thought about it. Then decided I'll never port this
>> code, so I used __int128. I then found that you can't write it out, so
>> I had to implement a string convert just to print the output!
> 
> Your post inspired me to do that myself (without having looked at the
> implementations for the standard integer types or thought about that at
> all ever before). This is what I came up with. It doesn't use
> std::string to avoid overhead and respects the basefield and showbase
> manipulators (but only them). What do you think?
> 
> 
> std::ostream& operator<<(std::ostream& out, signed __int128 k) {
>      if ((k<0) && (out.flags() & std::ios::dec)) {
>          out<<'-'; //output a minus sign
>          k*=-1; //change k to absolute value

Wouldn't this fail with INT128_MIN? Just nit-picking!

[toc] | [prev] | [next] | [standalone]

#122835

Am Tue, 7 Oct 2025 10:44:57 +0300
schrieb Paavo Helde <eesnimi@osa.pri.ee>:

> On 10/6/2025 6:34 PM, Ralf Goertz wrote:
>> Am Fri, 3 Oct 2025 17:05:38 +0100
>> schrieb Vir Campestris <vir.campestris@invalid.invalid>:
>>   
>>> On 29/09/2025 23:03, Michael S wrote:  
>>>> If you neeed just a little more than 64 bit then use 128-bit
>>>> integers. For decades gcc and clang feature a non-standard type
>>>> __int128.  
>>> I went away and thought about it. Then decided I'll never port this
>>> code, so I used __int128. I then found that you can't write it
>>> out, so I had to implement a string convert just to print the
>>> output!  
>> 
>> Your post inspired me to do that myself (without having looked at
>> the implementations for the standard integer types or thought about
>> that at all ever before). This is what I came up with. It doesn't
>> use std::string to avoid overhead and respects the basefield and
>> showbase manipulators (but only them). What do you think?
>> 
>> 
>> std::ostream& operator<<(std::ostream& out, signed __int128 k) {
>>      if ((k<0) && (out.flags() & std::ios::dec)) {
>>          out<<'-'; //output a minus sign
>>          k*=-1; //change k to absolute value  
> 
> Wouldn't this fail with INT128_MIN? Just nit-picking!

Hm, maybe it should. But it doesn't:

int main() {
    std::cout<<' '<<std::numeric_limits<signed __int128>::max()<<std::endl;
    std::cout<<     std::numeric_limits<signed __int128>::min()<<std::endl;
}

gives

 170141183460469231731687303715884105727
-170141183460469231731687303715884105728

First, I wanted to clear the sign bit “by hand” but it seemed overly
complicated and multiplying by -1 seemed to do the trick. And wouldn't
any method suffer from the same problem? Which might be why you added
the nit-picking remark. :-) OTOH, one could static_cast k to unsigned
first and then clear the bit.

[toc] | [prev] | [next] | [standalone]

#122798

On Mon, 29 Sep 2025 21:08:09 +0100
Vir Campestris <vir.campestris@invalid.invalid> wrote:

> I could knock something up - all I need to do is total a ****** lot
> of small numbers accurately, but the result is more than 64 bits.
> 
> Andy

To add to my previous post, if for some reason __int128 does not
satisfy your needs and if you don't want not switch to better language
then the simplest way to do it in "almost standard" C++ is to use
"almost standard" C++ library. I.e. boost.

www.boost.org/doc/libs/latest/libs/multiprecision/doc/html/boost_multiprecision/tut/ints/cpp_int.html

Not nearly as friction-free as __int128 and if you use it in multiple
places it can make your compilation noticeably slower, but at least
deployment is easy, both at development machine and at target. In fact,
being header-only, at target boost_multiprecision::cpp_int introduces no
dependencies at all.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c++

csiph-web