[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Using the GNU GMP Library for Bignums in Emacs

From: Siraphob (Ben) Phipathananunth
Subject: Re: Using the GNU GMP Library for Bignums in Emacs
Date: Sat, 21 Apr 2018 22:01:07 +0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0

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

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

> 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.


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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]