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

Groups > comp.lang.c > #27489 > unrolled thread

Large number libraries/algorithms

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

Contents

  Large number libraries/algorithms boltar2003@boltar.world - 2012-10-22 09:11 +0000
    Re: Large number libraries/algorithms Mark Bluemel <mark_bluemel@pobox.com> - 2012-10-22 10:15 +0100
    Re: Large number libraries/algorithms Heikki Kallasjoki <fis+usenet@zem.fi> - 2012-10-22 09:19 +0000
      Re: Large number libraries/algorithms boltar2003@boltar.world - 2012-10-22 09:40 +0000
    Re: Large number libraries/algorithms Noob <root@127.0.0.1> - 2012-10-22 11:24 +0200
    Re: Large number libraries/algorithms David Brown <david@westcontrol.removethisbit.com> - 2012-10-22 13:29 +0200
      Re: Large number libraries/algorithms boltar2003@boltar.world - 2012-10-22 11:53 +0000
        Re: Large number libraries/algorithms James Kuyper <jameskuyper@verizon.net> - 2012-10-22 08:01 -0400
          Re: Large number libraries/algorithms David Brown <david@westcontrol.removethisbit.com> - 2012-10-22 14:41 +0200
            Re: Large number libraries/algorithms James Kuyper <jameskuyper@verizon.net> - 2012-10-22 09:36 -0400
              Re: Large number libraries/algorithms Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-10-22 15:12 +0100
      Re: Large number libraries/algorithms Keith Thompson <kst-u@mib.org> - 2012-10-22 10:31 -0700
        Re: Large number libraries/algorithms Robert Wessel <robertwessel2@yahoo.com> - 2012-10-22 15:09 -0500
          Re: Large number libraries/algorithms Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-10-23 00:01 +0100
            Re: Large number libraries/algorithms David Brown <david@westcontrol.removethisbit.com> - 2012-10-23 09:38 +0200
              Re: Large number libraries/algorithms Steve Thompson <stevet810@gmail.com> - 2012-10-23 12:40 +0000
                Re: Large number libraries/algorithms David Brown <david@westcontrol.removethisbit.com> - 2012-10-23 16:23 +0200
                  Re: Large number libraries/algorithms Steve Thompson <stevet810@gmail.com> - 2012-10-23 14:38 +0000
              Re: Large number libraries/algorithms Keith Thompson <kst-u@mib.org> - 2012-10-23 12:58 -0700
                Re: Large number libraries/algorithms David Brown <david@westcontrol.removethisbit.com> - 2012-10-24 09:01 +0200
                  Re: Large number libraries/algorithms James Kuyper <jameskuyper@verizon.net> - 2012-10-24 07:18 -0400
                    Re: Large number libraries/algorithms David Brown <david@westcontrol.removethisbit.com> - 2012-10-24 14:23 +0200
                      Re: Large number libraries/algorithms Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-10-24 14:43 +0100
                        Re: Large number libraries/algorithms Keith Thompson <kst-u@mib.org> - 2012-10-24 11:33 -0700
                          Re: Large number libraries/algorithms Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-10-24 19:53 +0100
                      Re: Large number libraries/algorithms James Kuyper <jameskuyper@verizon.net> - 2012-10-24 10:50 -0400
                  Re: Large number libraries/algorithms Noob <root@localhost> - 2012-10-24 15:16 +0200
                    Re: Large number libraries/algorithms Noob <root@localhost> - 2012-10-24 18:57 +0200
                      Re: Large number libraries/algorithms Keith Thompson <kst-u@mib.org> - 2012-10-24 11:43 -0700
                        Re: Large number libraries/algorithms David Brown <david@westcontrol.removethisbit.com> - 2012-10-25 09:05 +0200
    Re: Large number libraries/algorithms Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-10-22 08:23 -0400
      Re: Large number libraries/algorithms tom st denis <tom@iahu.ca> - 2012-10-22 11:40 -0700
        Re: Large number libraries/algorithms Keith Thompson <kst-u@mib.org> - 2012-10-22 17:05 -0700
          Re: Large number libraries/algorithms tom st denis <tom@iahu.ca> - 2012-10-23 07:10 -0700
    Re: Large number libraries/algorithms David Brown <david@westcontrol.removethisbit.com> - 2012-10-22 14:42 +0200
      Re: Large number libraries/algorithms Chad <cdalten@gmail.com> - 2012-10-23 14:39 -0700
    Re: Large number libraries/algorithms pete <pfiland@mindspring.com> - 2012-10-24 03:27 -0400

Page 2 of 2 — ← Prev page 1 [2]

#27626

On 10/24/2012 03:01 AM, David Brown wrote:
...
> I noticed that (on gcc 4.5 on Linux-64).  There is also no int128_t or 
> related types in <stdint.h>.  And there is no way to express an int128_t 
> literal for targets that whose "long long" is smaller than 128 bits.  On 
> x86-64, "long long" is 64-bit (with "long" being 32-bit on Windows, 
> 64-bit on Linux), so until "long long long int" or "really long int" is 
> added to C, the language is missing a bit of support for 128-bit integers.

There's no need for that - that's what int128_t, int_least128_t and
int_fast128_t are reserved for. The language isn't missing anything,
it's just that particular implementation which has failed to implement
something which is already part of the language.
-- 
James Kuyper

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

#27630

On 24/10/2012 13:18, James Kuyper wrote:
> On 10/24/2012 03:01 AM, David Brown wrote:
> ...
>> I noticed that (on gcc 4.5 on Linux-64).  There is also no int128_t or
>> related types in <stdint.h>.  And there is no way to express an int128_t
>> literal for targets that whose "long long" is smaller than 128 bits.  On
>> x86-64, "long long" is 64-bit (with "long" being 32-bit on Windows,
>> 64-bit on Linux), so until "long long long int" or "really long int" is
>> added to C, the language is missing a bit of support for 128-bit integers.
>
> There's no need for that - that's what int128_t, int_least128_t and
> int_fast128_t are reserved for. The language isn't missing anything,
> it's just that particular implementation which has failed to implement
> something which is already part of the language.
>

Yes, these type names are suitable for that purpose (though I am not 
sure they are reserved for it by C99) - and it is the implementation 
here that has failed to include them in <stdint.h> (I am not sure 
whether this is the responsibility of the compiler or the library).


However, it is possible to express a 32-bit zero as "0", and a 64-bit 
("long long") zero as "0LL".  But there is no way to write a literal 
128-bit zero, without extending C to allow "0LLL".

The "int128_t" and related types are enough to do most 128-bit integer 
work in C.  But there are unfortunately a number of places where the C 
language and library specifications are tied to the poorly-defined 
"int", "short", "long", "long long" types rather than size-specific 
types.  This includes the suffixes on literals, and the format 
specifiers in printf() (the "PRId32" style macros help enormously, but 
they are not exactly elegant - and since they expand to specifiers for 
short, int, long or long long, they can't support 128-bit integers).


On the other hand, I don't see how this would limit practical 128-bit 
usage much.  After all, how often do you need to write 128-bit literals, 
or printf them out?

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

#27634

David Brown <david@westcontrol.removethisbit.com> writes:

> On 24/10/2012 13:18, James Kuyper wrote:
>> On 10/24/2012 03:01 AM, David Brown wrote:
>> ...
>>> I noticed that (on gcc 4.5 on Linux-64).  There is also no int128_t or
>>> related types in <stdint.h>.  And there is no way to express an int128_t
>>> literal for targets that whose "long long" is smaller than 128 bits.  On
>>> x86-64, "long long" is 64-bit (with "long" being 32-bit on Windows,
>>> 64-bit on Linux), so until "long long long int" or "really long int" is
>>> added to C, the language is missing a bit of support for 128-bit integers.
>>
>> There's no need for that - that's what int128_t, int_least128_t and
>> int_fast128_t are reserved for. The language isn't missing anything,
>> it's just that particular implementation which has failed to implement
>> something which is already part of the language.
>>
>
> Yes, these type names are suitable for that purpose (though I am not
> sure they are reserved for it by C99) - and it is the implementation
> here that has failed to include them in <stdint.h> (I am not sure
> whether this is the responsibility of the compiler or the library).

I commented on this a couple of days ago.  I image the fact that
__int128 is in the compiler but int128_t is not it stdint.h is simply
the desire to keep the number of versions of stdint.h to a minimum.
Since C99 requires at least a 64-but int, limiting yourself to that
length keeps stdint.h very simple.  However, I don't think gcc has the
mechanisms in place to make intmax_t be the 128-bit type (see below) and
that may be the real reason stdint.h stop st 64-bit types.

(A further reason might be simply that if you provide int128_t intmax_t
must be this type and all pre-processor arithmetic must be done using
it -- or at least *as if* it were being used.)

> However, it is possible to express a 32-bit zero as "0", and a 64-bit
> ("long long") zero as "0LL".  But there is no way to write a literal
> 128-bit zero, without extending C to allow "0LLL".
>
> The "int128_t" and related types are enough to do most 128-bit integer
> work in C.  But there are unfortunately a number of places where the C
> language and library specifications are tied to the poorly-defined
> "int", "short", "long", "long long" types rather than size-specific
> types.

But an implementation that has a 128-bit int can provide some
system-specific suffix (or, indeed, some other syntax) and stdint.h can
hide it to make the code portable.  If your program needs a 128-bit
integer, you should be able to use int_least128_t and write constants
using INT128_C(value).  gcc has provided __int128 but there is no
extension to write 128-bit constants yet.  This may be the another
reason that stdint.h stops where it does.

>  This includes the suffixes on literals, and the format
> specifiers in printf() (the "PRId32" style macros help enormously, but
> they are not exactly elegant - and since they expand to specifiers for
> short, int, long or long long, they can't support 128-bit integers).

I don't think that true.  PRId128 could expand to some reserved but
currently unused length specifier.  I don't think these macros are
limited to the specifiers for the standard integer types.

> On the other hand, I don't see how this would limit practical 128-bit
> usage much.  After all, how often do you need to write 128-bit
> literals, or printf them out?
>

-- 
Ben.

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

#27640

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
[...]
> I commented on this a couple of days ago.  I image the fact that
> __int128 is in the compiler but int128_t is not it stdint.h is simply
> the desire to keep the number of versions of stdint.h to a minimum.
> Since C99 requires at least a 64-but int, limiting yourself to that
> length keeps stdint.h very simple.  However, I don't think gcc has the
> mechanisms in place to make intmax_t be the 128-bit type (see below) and
> that may be the real reason stdint.h stop st 64-bit types.

If gcc provided an implementation-defined macro that indicates
whether __int128 is available, then <stdint.h> could use that macro
to decide whether to define int128_t and friends, and how to define
intmax_t.  (<stdint.h> is provided by glibc, or by whatever C library
is used on a given system -- I don't know whether it uses fixincludes
to generate a compatible <stdint.h> on non-glibc systems).

Incidentally, gcc's syntax for its 128-bit unsigned type is

    unsigned __int128

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#27642

Keith Thompson <kst-u@mib.org> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> [...]
>> I commented on this a couple of days ago.  I image the fact that
>> __int128 is in the compiler but int128_t is not it stdint.h is simply
>> the desire to keep the number of versions of stdint.h to a minimum.
>> Since C99 requires at least a 64-but int, limiting yourself to that
>> length keeps stdint.h very simple.  However, I don't think gcc has the
>> mechanisms in place to make intmax_t be the 128-bit type (see below) and
>> that may be the real reason stdint.h stop st 64-bit types.
>
> If gcc provided an implementation-defined macro that indicates
> whether __int128 is available, then <stdint.h> could use that macro
> to decide whether to define int128_t and friends, and how to define
> intmax_t.

Yes, that's the easy part!  When I said that gcc does not have the
mechanisms in place I was referring to ability to write a literal with
the right type.  If stdint.h provides access to this 128-bit type it
must also provide INT128_C and that's probably a gcc issue.

<snip>
-- 
Ben.

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

#27635

On 10/24/2012 08:23 AM, David Brown wrote:
> On 24/10/2012 13:18, James Kuyper wrote:
>> On 10/24/2012 03:01 AM, David Brown wrote:
>> ...
>>> I noticed that (on gcc 4.5 on Linux-64).  There is also no int128_t or
>>> related types in <stdint.h>.  And there is no way to express an int128_t
>>> literal for targets that whose "long long" is smaller than 128 bits.  On
>>> x86-64, "long long" is 64-bit (with "long" being 32-bit on Windows,
>>> 64-bit on Linux), so until "long long long int" or "really long int" is
>>> added to C, the language is missing a bit of support for 128-bit integers.
>>
>> There's no need for that - that's what int128_t, int_least128_t and
>> int_fast128_t are reserved for. The language isn't missing anything,
>> it's just that particular implementation which has failed to implement
>> something which is already part of the language.
>>
> 
> Yes, these type names are suitable for that purpose (though I am not 
> sure they are reserved for it by C99)

If <stdint.h> is #included, C99 defines what those names mean for all N,
while only making the least and fast types mandatory for N = 8, 16, 32,
and 64. Conversely, the standard prohibits <stdint.h> from defining
those names for values of N for which the corresponding types are
unsupported.

Since those typedefs and macros do not have external linkage, but do
have file scope, the corresponding identifiers are reserved only if
<stdint.h> is #included; otherwise, they're in the name space reserved
for users, which means that an implementation is NOT free to give them
any other meaning.

> - and it is the implementation 
> here that has failed to include them in <stdint.h> (I am not sure 
> whether this is the responsibility of the compiler or the library).

The library can't do anything to make it work unless the compiler
supports a type of the right size; but the corresponding typedef must
not be defined unless and until the standard header is #included, so it
seems to me that they must both work together. Also, support for 128-bit
integers will probably affect [u]intmax_t, and therefore also the
corresponding functions from <stdint.h>, and the printf()/scanf() family.

> However, it is possible to express a 32-bit zero as "0", and a 64-bit 
> ("long long") zero as "0LL".  But there is no way to write a literal 
> 128-bit zero, without extending C to allow "0LLL".

That's what the INTN_C macros are for. They're clumsy, but they do the job:

#include <stdint.c>
#ifndef INT128_MAX
#error 128 bit types not supported
#endif

int128_t i128 = INT128_C(0);

Unless int128_t is a typedef for a standard type, INT128_C() will have
to do something implementation-specific to mark it as an int128_t value.
Keeping in mind that the result must be suitable for use in #if
preprocessing directives, it can't be something like ((int128_t)0),
because, for the purposes of such directives, that would parse as
((0)0), which is a syntax error. It might very well, as an
implementation-specific extension, expand to 0LLL. However, your code
doesn't have to know about that; all it needs to know is whether or not
INT128_MAX is #defined. If so, it can use INT128_C().

> The "int128_t" and related types are enough to do most 128-bit integer 
> work in C.  But there are unfortunately a number of places where the C 
> language and library specifications are tied to the poorly-defined 
> "int", "short", "long", "long long" types rather than size-specific 
> types.  This includes the suffixes on literals, and the format 
> specifiers in printf() (the "PRId32" style macros help enormously, but 
> they are not exactly elegant - and since they expand to specifiers for 
> short, int, long or long long, they can't support 128-bit integers).

There's no requirement that PRId128 expand into a specifier for short,
int, long, or long long. There is, on the other hand, a requirement that
if PRId128 is #defined, it must expand into a format specifier "suitable
for use ... when converting" int128_t. That specifier might be
implementation-specific, unless int128_t happens to be the same typedef
for a standard type, but it must exist.

> On the other hand, I don't see how this would limit practical 128-bit 
> usage much.  After all, how often do you need to write 128-bit literals, 
> or printf them out?

I'm sure that if I needed to work with 128-bit data, I would need to
write them and to printf() them out. Luckily, as explained above, that's
not a problem.

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

#27633

David Brown wrote:

> I noticed that (on gcc 4.5 on Linux-64).  There is also no int128_t
> or related types in <stdint.h>.  And there is no way to express an
> int128_t literal for targets whose "long long" is smaller than 128
> bits.  On x86-64, "long long" is 64-bit (with "long" being 32-bit on
> Windows, 64-bit on Linux), so until "long long long int" or "really
> long int" is added to C, the language is missing a bit of support for
> 128-bit integers.

I was under the impression that there existed an obscure GCC-specific
syntax to define 128-bit integer types:

  typedef unsigned int myUI64 __attribute__((mode(TI)));

http://gcc.gnu.org/onlinedocs/gcc/Variable-Attributes.html

mode(foo)
  This attribute specifies the data type for the declaration,
  whichever type corresponds to the mode foo. This in effect
  lets you request an integer or floating point type according
  to its width.

Not sure what one can then do with an object of type myUI64.
(add? sub? shift? mul? div?)
And perhaps this has been obsolete for a long time?

cf. also
http://gcc.gnu.org/onlinedocs/gcc/_005f_005fint128.html
http://stackoverflow.com/questions/4559025/what-does-gcc-attribute-modexx-actually-do

On a somewhat related note, cf. also:
http://locklessinc.com/articles/256bit_arithmetic/

Regards.

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

#27636

Noob wrote:

> I was under the impression that there existed an obscure GCC-specific
> syntax to define 128-bit integer types:
> 
>   typedef unsigned int myUI64 __attribute__((mode(TI)));

Errr, I meant myUI128.

And IIUC, one may also define a 256-bit integer type with

  typedef unsigned int myUI256 __attribute__((mode(OI)));

sizeof(myUI256) is supposed to yield 32, which seems to imply(?)
that these type definitions fall apart when CHAR_BIT != 8

Regards.

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

#27641

Noob <root@localhost> writes:
> Noob wrote:
>> I was under the impression that there existed an obscure GCC-specific
>> syntax to define 128-bit integer types:
>> 
>>   typedef unsigned int myUI64 __attribute__((mode(TI)));
>
> Errr, I meant myUI128.
>
> And IIUC, one may also define a 256-bit integer type with
>
>   typedef unsigned int myUI256 __attribute__((mode(OI)));

Yes, that seems to work -- but since neither "mode(TI)" nor "mode(OI)"
appears in the gcc documentation, I wouldn't count on them being
supported.  For the latter, I get "error: unable to emulate 'OI'".

> sizeof(myUI256) is supposed to yield 32, which seems to imply(?)
> that these type definitions fall apart when CHAR_BIT != 8

I don't think gcc supports CHAR_BIT!=8.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#27668

On 24/10/2012 20:43, Keith Thompson wrote:
> Noob <root@localhost> writes:
>> Noob wrote:
>>> I was under the impression that there existed an obscure GCC-specific
>>> syntax to define 128-bit integer types:
>>>
>>>    typedef unsigned int myUI64 __attribute__((mode(TI)));
>>

The "mode" attribute is used in a number of gcc targets to provide 
unusual integer sizes (such as 20-bit, 24-bit and 40-bit integers 
supported by some cpus), as well as odd pointer types.  You don't use 
them much (if at all) as a normal user, but you can see them in library 
and system headers for some targets.

>> Errr, I meant myUI128.
>>
>> And IIUC, one may also define a 256-bit integer type with
>>
>>    typedef unsigned int myUI256 __attribute__((mode(OI)));
>
> Yes, that seems to work -- but since neither "mode(TI)" nor "mode(OI)"
> appears in the gcc documentation, I wouldn't count on them being
> supported.  For the latter, I get "error: unable to emulate 'OI'".
>
>> sizeof(myUI256) is supposed to yield 32, which seems to imply(?)
>> that these type definitions fall apart when CHAR_BIT != 8
>
> I don't think gcc supports CHAR_BIT!=8.
>

I believe it does, though I haven't used any gcc ports where CHAR_BIT is 
not 8.  gcc supports a lot of different targets, including some DSP 
architectures which I think have CHAR_BIT of 16.  I have also read 
somewhere about gcc for the PDP-10 with CHAR_BIT = 9.

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

#27501

On 10/22/2012 5:11 AM, boltar2003@boltar.world wrote:
> Does anyone know of an API that will do standard math ops (*,+,-,/,% etc) on
> very large numbers (stored in char arrays presumably)? ie The sort of numbers
> that have no chance of fitting in even a 64 bit int or double. Or failing
> that is there a good site explaining how to implement them yourself?

     This is Question 18.15d on the comp.lang.c Frequently Asked
Questions (FAQ) page at <http://www.c-faq.com/>.

-- 
Eric Sosman
esosman@comcast-dot-net.invalid

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

#27527

On Oct 22, 8:23 am, Eric Sosman <esos...@comcast-dot-net.invalid>
wrote:
> On 10/22/2012 5:11 AM, boltar2...@boltar.world wrote:
>
> > Does anyone know of an API that will do standard math ops (*,+,-,/,% etc) on
> > very large numbers (stored in char arrays presumably)? ie The sort of numbers
> > that have no chance of fitting in even a 64 bit int or double. Or failing
> > that is there a good site explaining how to implement them yourself?
>
>      This is Question 18.15d on the comp.lang.c Frequently Asked
> Questions (FAQ) page at <http://www.c-faq.com/>.

Someone really needs to update that response...

Tom

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

#27554

tom st denis <tom@iahu.ca> writes:
> On Oct 22, 8:23 am, Eric Sosman <esos...@comcast-dot-net.invalid>
> wrote:
>> On 10/22/2012 5:11 AM, boltar2...@boltar.world wrote:
>>
>> > Does anyone know of an API that will do standard math ops (*,+,-,/,% etc) on
>> > very large numbers (stored in char arrays presumably)? ie The sort of numbers
>> > that have no chance of fitting in even a 64 bit int or double. Or failing
>> > that is there a good site explaining how to implement them yourself?
>>
>>      This is Question 18.15d on the comp.lang.c Frequently Asked
>> Questions (FAQ) page at <http://www.c-faq.com/>.
>
> Someone really needs to update that response...

Update it how?

If you have an update, there's a feedback link on each page, or
you can send e-mail to Steve Summit.  It doesn't look like there
have been any updates since 2005.  I don't know Steve's level of
interest in updating it.  (Some information on C11 would be nice.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#27574

On Oct 22, 8:05 pm, Keith Thompson <ks...@mib.org> wrote:
> tom st denis <t...@iahu.ca> writes:
>
> > On Oct 22, 8:23 am, Eric Sosman <esos...@comcast-dot-net.invalid>
> > wrote:
> >> On 10/22/2012 5:11 AM, boltar2...@boltar.world wrote:
>
> >> > Does anyone know of an API that will do standard math ops (*,+,-,/,% etc) on
> >> > very large numbers (stored in char arrays presumably)? ie The sort of numbers
> >> > that have no chance of fitting in even a 64 bit int or double. Or failing
> >> > that is there a good site explaining how to implement them yourself?
>
> >>      This is Question 18.15d on the comp.lang.c Frequently Asked
> >> Questions (FAQ) page at <http://www.c-faq.com/>.
>
> > Someone really needs to update that response...
>
> Update it how?
>
> If you have an update, there's a feedback link on each page, or
> you can send e-mail to Steve Summit.  It doesn't look like there
> have been any updates since 2005.  I don't know Steve's level of
> interest in updating it.  (Some information on C11 would be nice.)

The current answer reads:

"Some popular packages are the ``quad'' functions within the BSD Unix
libc sources (ftp.uu.net, /systems/unix/bsd-sources/.../src/lib/libc/
quad/*), the GNU MP library ``libmp'', the MIRACL package (see
http://indigo.ie/~mscott/), the ``calc'' program by David Bell and
Landon Curt Noll, and the old Unix libmp.a."

I doubt "quad" has been maintained for a long time.  I can't even get
on the ftp.uu.net server let alone check the status of the package.
GMP is called libgmp.a (fairly certain) and has been for a while.
MIRACL is proprietary, etc...

There are plenty of more modern packages.  GMP being one [updated ref
maybe link], the LTM/TFM libraries I worked on back in the day (though
unmaintained are still useful and perform great on modern machines).
The LTM library I wrote for instance is the basis for the bignum
support in Tcl.  It's also used by HP on some of their newer
calculators to perform arbitrary precision math internally, etc...

I wouldn't expect a CFAQ maintainer to know about these things, but it
probably wouldn't hurt to google around once in a while...

Tom

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

#27503

On 22/10/2012 11:11, boltar2003@boltar.world wrote:
> Does anyone know of an API that will do standard math ops (*,+,-,/,% etc) on
> very large numbers (stored in char arrays presumably)? ie The sort of numbers
> that have no chance of fitting in even a 64 bit int or double. Or failing
> that is there a good site explaining how to implement them yourself?
>
> Thanks for any info
>
> B2003
>


Another question here is do you have to use C?  You might be better off 
using a language like Python that handles arbitrary precision integers 
directly (probably using GMP behind the scenes).

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

#27607

On Monday, October 22, 2012 5:47:31 AM UTC-7, David Brown wrote:
> On 22/10/2012 11:11, boltar2003@boltar.world wrote:
> 
> > Does anyone know of an API that will do standard math ops (*,+,-,/,% etc) on
> 
> > very large numbers (stored in char arrays presumably)? ie The sort of numbers
> 
> > that have no chance of fitting in even a 64 bit int or double. Or failing
> 
> > that is there a good site explaining how to implement them yourself?
> 
> >
> 
> > Thanks for any info
> 
> >
> 
> > B2003
> 
> >
> 
> 
> 
> 
> 
> Another question here is do you have to use C?  You might be better off 
> 
> using a language like Python that handles arbitrary precision integers 
> 
> directly (probably using GMP behind the scenes).


What about Haskell?

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

#27620

boltar2003@boltar.world wrote:
> 
> Does anyone know of an API that will do standard math ops
> (*,+,-,/,% etc) on
> very large numbers (stored in char arrays presumably)?
> ie The sort of numbers
> that have no chance of fitting in even a 64 bit int or double.
> Or failing
> that is there a good site explaining how to implement them yourself?
> 
> Thanks for any info

If you google on "PI_FFTCA"
you can find software in C by Takuya Ooura
for that kind of thing.

PI_FFTCA.C calculates a whole lot of pi, very quickly.

-- 
pete

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web