Re: Using the GNU GMP Library for Bignums in Emacs

[Siraphob (Ben) Phipathananunth]

One approach would be to implement a minimal subset of functions
exposed in Emacs Lisp that would allow one to recreate the following
functions that are defined in calc.el :

Function Name              Arguments
============================================
math-bignum                (a)
math-bignum-big            (a)
math-div10-bignum          (a)
math-scale-left-bignum     (a n)
math-scale-right-bignum    (a n)
math-add-bignum            (a b)
math-sub-bignum            (a b)
math-mul-bignum            (a b)
math-mul-bignum-digit      (a d c)
math-div-bignum            (a b)
math-div-bignum-digit      (a b)
math-div-bignum-big        (a b alen blen)
math-div-bignum-part       (a b blen)
math-div-bignum-try        (a b c guess)
math-format-bignum         (a)
math-format-bignum-decimal (a)
math-read-bignum           (s)

There are other functions scattered throughout the calc sources, but
this is the rough idea of the type of functions we would need. This
list would have to be shortened, as when we migrate bignums we would
no longer need the following functions (at least, could be more):

math-mul-bignum-digit      (a d c)
math-div-bignum-digit      (a b)

These functions exist because bignums are implemented as a list of
digits.

I think that keeping the function names the same would be good (for
some backwards compatibility). The /actual/ value of the bignum
(internally, in C) would be a tagged pointer to the mpz_t data type
stored somewhere so that it could be marked for GC (very important to
mark for GC).

With respect to floating points, though, things get a little hairy.

As quoted from the GMP Library
(https://gmplib.org/manual/Floating_002dpoint-Functions.html):

> The exponent of each float has fixed precision, one machine word on
> most systems. In the current implementation the exponent is a count of
> limbs, so for example on a 32-bit system this means a range of roughly
> 2^-68719476768 to 2^68719476736, or on a 64-bit system this will be
> much greater. Note however that mpf_get_str can only return an
> exponent which fits an mp_exp_t and currently mpf_set_str doesn’t
> accept exponents bigger than a long.

Fortunately, it links to another project called MPFR
http://www.mpfr.org/sample.html which allows us to computing floating
points at arbitrary precision.

However, I'm concerned that adding two different libraries could lead
to issues regarding interoperability (for example, a floating point
number that needs to be converted to a bignum, and vice versa). If
anyone has used MPFR + GMP in the past, please chime in.

GC shouldn't be ignored as well, because as the name implies, these
data objects would be very large.

Thanks,

Siraphob (Ben) Phipathananunth

Eli Zaretskii wrote:
> > From: "Siraphob (Ben) Phipathananunth" <address@hidden>
> > Date: Sat, 21 Apr 2018 21:15:08 +0700
> >
> > Emacs Calc was written many years ago, and as a result its current
> > implementation implements bignums purely in Emacs Lisp. Its bignum
> > operations also use a lot of hacks (such as performing carry
> > operations). Arbitrary precision arithmetic could be faster if Emacs
> > had GNU GMP linked to it, with the relevant Emacs Lisp functions added
> > in C.
> >
> > What is the consensus on linking the GNU GMP library to Emacs so that
> > packages such as Emacs Calc (and others) could benefit from using
> > native types (i.e. "mpz_t") rather than reinventing the wheel?
>
> I think the consensus is we want that, it's just a matter of someone
> doing the job of making it happen.
>
> The design should IMO be discussed up front, because we want not only
> to be able to use bignums and arbitrary-precision floating-point
> numbers in C, but also in Lisp.  How exactly to expose them to Lisp is
> something we should talk about, I think.
>
> Thanks.