From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: "Siraphob (Ben) Phipathananunth" Newsgroups: gmane.emacs.devel Subject: Re: Using the GNU GMP Library for Bignums in Emacs Date: Sat, 21 Apr 2018 22:01:07 +0700 Message-ID: References: <29f933ac-a6bf-8742-66a7-0a9d6d3e5a88@disroot.org> <83bmecy6fx.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1524322765 21596 195.159.176.226 (21 Apr 2018 14:59:25 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 21 Apr 2018 14:59:25 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Apr 21 16:59:20 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f9tyy-0005Y8-05 for ged-emacs-devel@m.gmane.org; Sat, 21 Apr 2018 16:59:20 +0200 Original-Received: from localhost ([::1]:50435 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f9u14-0001Dt-U7 for ged-emacs-devel@m.gmane.org; Sat, 21 Apr 2018 11:01:30 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43754) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f9u0x-0001DL-TD for emacs-devel@gnu.org; Sat, 21 Apr 2018 11:01:25 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f9u0t-0002yb-Qk for emacs-devel@gnu.org; Sat, 21 Apr 2018 11:01:23 -0400 Original-Received: from knopi.disroot.org ([178.21.23.139]:37556) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1f9u0o-0002vl-LD; Sat, 21 Apr 2018 11:01:15 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by disroot.org (Postfix) with ESMTP id 2C9012DD9C; Sat, 21 Apr 2018 17:01:13 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=disroot.org; s=mail; t=1524322873; bh=2LneSyATDk3jKT9CSvaV/kK5ylLVq673OwPEp3tow0c=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=I4XY+PyMYxa1YyRXXaoF0vIosk0yzh+c+MyMBGW/nGNUuP/C52JhXDNtjo5Sm62ND TihF6zwqKOZbH8bQIajOK18Mk/Xss5bp855o8Q5W2zNygGwuiD7jsm3HxKTUhcdphM XEe8n9JlKflhArQqKJxf7+gDZMYFV13BMf5jGQFO7anaxDSWrPZz4xsCXUVGbTPYZR Wj7tR3jXqHmSUNktUPY4zf5UXTR7kc5vUWpKXQaPSrgKArr5PsrkEO3G0rd1frv+KW P9rE2st4f9MSajuL8hxaM8i07XDUAewbk2qdPkTu5XCs60T7Jc6reG34YA5R0pIKfB KBsQ+L7hwEniA== X-Virus-Scanned: Debian amavisd-new at disroot.org Original-Received: from knopi.disroot.org ([127.0.0.1]) by localhost (mail01.disroot.lan [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BGlDPGC3E3sR; Sat, 21 Apr 2018 17:01:11 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=disroot.org; s=mail; t=1524322871; bh=2LneSyATDk3jKT9CSvaV/kK5ylLVq673OwPEp3tow0c=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=l9JH1uwewhgy5jCB8DyRoeEzIGTFbVDVNhnnY4SwmiVLyRgyHIuSRj9Yq9cpqr8LF T8dZ8P75skgDvw0AYOLFw6qdi8wgJnLKlF7tC/zsZoI7GpSkP6Ut3ZpeDJz3pWPKrr FUzX5tG4rLGI1IEfbLZ4SXFrDP8IMr/Bseum3y7qmR7wTLm85R/1i9y1uqHsoN/c3W dDr28nf6b87JOvTDYEzuZxVe3O2XtzRpiCQXUzyP7+fXlGXyZ7puW0wdKlvRrTG76g aKX3NY3/cUSFZv4zY1CV49XLEq9FlbmOZTfe5b5Tz4PkN+hY6toasGTnyjQ+t3k5Zi 5izQbXt8Xetcg== In-Reply-To: <83bmecy6fx.fsf@gnu.org> Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 178.21.23.139 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:224762 Archived-At: 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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 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=E2=80=99= 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" >> 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? >=20 > I think the consensus is we want that, it's just a matter of someone > doing the job of making it happen. >=20 > 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. >=20 > Thanks. >=20