From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Mark H Weaver Newsgroups: gmane.lisp.guile.bugs Subject: bug#10519: guile and (mini-)gmp Date: Mon, 16 Jan 2012 05:19:33 -0500 Message-ID: <87aa5o2bm2.fsf@netris.org> References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1326709291 27010 80.91.229.12 (16 Jan 2012 10:21:31 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 16 Jan 2012 10:21:31 +0000 (UTC) Cc: 10519@debbugs.gnu.org, Torbjorn Granlund To: nisse@lysator.liu.se (Niels =?UTF-8?Q?M=C3=B6ller?=) Original-X-From: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Mon Jan 16 11:21:24 2012 Return-path: Envelope-to: guile-bugs@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Rmjgm-0000Sg-5W for guile-bugs@m.gmane.org; Mon, 16 Jan 2012 11:21:20 +0100 Original-Received: from localhost ([::1]:41387 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rmjgl-0003dw-Eb for guile-bugs@m.gmane.org; Mon, 16 Jan 2012 05:21:19 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:32971) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rmjgh-0003bj-Uo for bug-guile@gnu.org; Mon, 16 Jan 2012 05:21:17 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rmjga-0006T3-Lq for bug-guile@gnu.org; Mon, 16 Jan 2012 05:21:15 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:36304) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rmjga-0006St-K5 for bug-guile@gnu.org; Mon, 16 Jan 2012 05:21:08 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1RmjhR-0001Vp-Ol for bug-guile@gnu.org; Mon, 16 Jan 2012 05:22:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Mark H Weaver Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-guile@gnu.org Resent-Date: Mon, 16 Jan 2012 10:22:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10519 X-GNU-PR-Package: guile X-GNU-PR-Keywords: Original-Received: via spool by 10519-submit@debbugs.gnu.org id=B10519.13267092765736 (code B ref 10519); Mon, 16 Jan 2012 10:22:01 +0000 Original-Received: (at 10519) by debbugs.gnu.org; 16 Jan 2012 10:21:16 +0000 Original-Received: from localhost ([127.0.0.1]:59209 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Rmjgh-0001UR-Rf for submit@debbugs.gnu.org; Mon, 16 Jan 2012 05:21:16 -0500 Original-Received: from world.peace.net ([96.39.62.75]:58661) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Rmjge-0001UI-IW for 10519@debbugs.gnu.org; Mon, 16 Jan 2012 05:21:13 -0500 Original-Received: from c-98-216-245-176.hsd1.ma.comcast.net ([98.216.245.176] helo=yeeloong) by world.peace.net with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from ) id 1Rmjff-0007ma-Rf; Mon, 16 Jan 2012 05:20:12 -0500 In-Reply-To: ("Niels \=\?utf-8\?Q\?M\?\= \=\?utf-8\?Q\?\=C3\=B6ller\=22's\?\= message of "Sun, 15 Jan 2012 22:22:16 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 140.186.70.43 X-BeenThere: bug-guile@gnu.org List-Id: "Bug reports for GUILE, GNU's Ubiquitous Extension Language" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Original-Sender: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.bugs:6045 Archived-At: Hi Niels, thanks for looking into this! nisse@lysator.liu.se (Niels M=C3=B6ller) writes: > 2. The next problem is maybe more a nuisance than a real problem. I'm > looking at scm_i_big2dbl, in numbers.c. > > I notice this code doesn't currently use mpz_get_d (comment says > that's because gmp-4.2 and earlier didn't do well-defined rounding). > > Next, mpz_get_d in current gmp rounds towards zero. guile wants > rounding to nearest, and it arranges this by testing the next lower > bit. Unfortunately, it can't use mpz_tstbit directly, since for > negative values it needs the bit of the abolute value, not of the > two's complement. The code instead uses mpz_getlimbn and > GMP_NUMB_BITS. > > That's not an unreasonable way to do it, but it causes problems for > me because mini-gmp.h doesn't declare GMP_NUMB_BITS (and can't do, Don't worry about this. I have a patch set that (among other things) reimplements scm_i_big2dbl in a much more robust way, with proper rounding, and without using such low-level GMP accessors. I posted this patch set to guile-devel on 7 Oct, "[PATCH] Improvements to exact rationals et al". I will resubmit it soon. > 3. Occcasional use of mpq functions (do_divide, scm_inexact_to_exact), > for conversion of fradctions to and from doubles. mini-gmp has no > mpq-functions (and it shouldn't have), so these calls have to either > be eliminated altogether, or be made conditional on HAVE_LIBGMP. > > For conversion double->fraction, mpq seems overkill: Just multiply by > a power of two to make the number an integer, to construct a fraction > p / 2^k, and then eliminate any common factors of two (if fractions > are required to be in some canonical form). Agreed. I can easily reimplement this to avoid the mpq functions, and will do so. > For fraction->double, I think the current code using mpq_get_d rounds > towards zero rather than towards nearest, which might not be what's > desired. To avoid using mpq, I think converting p/q to a double could > be done as follows: The aforementioned patch set already eliminates this use of the mpq functions. > 4. mini-gmp has no mp_set_memory_functions. If I understand the the > conservative gc used with guile right, having mini-gmp always use > plain malloc and free should not cause any errors, just a slight > waste of memory in case some limbs happen to be valid pointers. No, it's much worse than that. If most of the memory being allocated are bignums, then GC might not be run until the heap is quite large. That's because the GC decides when to run based on the allocations that it knows about. A potentially large amount of bignum data may be allocated before the GC heap gets big enough to trigger a collection. It doesn't know about memory allocated with plain malloc. However, it _does_ now know about memory allocated with scm_malloc. It would be good if you could duplicate the `mp_set_memory_functions' interface in mini-gmp. Thanks, Mark