unofficial mirror of bug-guile@gnu.org 
 help / color / mirror / Atom feed
From: Mark H Weaver <mhw@netris.org>
To: nisse@lysator.liu.se (Niels Möller)
Cc: 10519@debbugs.gnu.org, Torbjorn Granlund <tg@gmplib.org>
Subject: bug#10519: guile and (mini-)gmp
Date: Mon, 16 Jan 2012 05:19:33 -0500	[thread overview]
Message-ID: <87aa5o2bm2.fsf@netris.org> (raw)
In-Reply-To: <nnmx9oy83b.fsf@stalhein.lysator.liu.se> ("Niels \=\?utf-8\?Q\?M\?\= \=\?utf-8\?Q\?\=C3\=B6ller\=22's\?\= message of "Sun, 15 Jan 2012 22:22:16 +0100")

Hi Niels, thanks for looking into this!

nisse@lysator.liu.se (Niels Möller) 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





  reply	other threads:[~2012-01-16 10:19 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-15 21:22 bug#10519: guile and (mini-)gmp Niels Möller
2012-01-16 10:19 ` Mark H Weaver [this message]
2012-01-16 14:06   ` Niels Möller
2012-01-16 19:21     ` Mark H Weaver
2012-01-28  9:49   ` Niels Möller
2012-01-28 10:10     ` Mark H Weaver
2012-07-22  9:04   ` Ludovic Courtès
2012-02-03 13:40 ` Andy Wingo
2012-02-03 19:56   ` Niels Möller
2012-02-03 20:01     ` Torbjorn Granlund
2012-02-04 22:46       ` Ludovic Courtès
2012-07-22  9:00 ` Ludovic Courtès
2012-07-22 23:17   ` Niels Möller
2012-08-10 21:51     ` Ludovic Courtès
2012-08-11  9:37       ` Niels Möller
2012-08-11 19:46         ` Ludovic Courtès
2012-08-11 21:50           ` Niels Möller
2012-08-11 22:48             ` Ludovic Courtès
2013-03-02 20:04               ` Andy Wingo
2013-03-02 20:58                 ` Mark H Weaver
2013-03-05 19:09                   ` Mark H Weaver
2013-03-18  0:01                     ` Mark H Weaver
2013-03-18  9:19                       ` Ludovic Courtès
2013-03-26  8:17                       ` Niels Möller
2013-03-27 17:00                         ` Mark H Weaver
2016-10-27 12:29                       ` Niels Möller
2016-11-10 19:56                         ` Andy Wingo
2013-03-02 21:45                 ` Niels Möller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87aa5o2bm2.fsf@netris.org \
    --to=mhw@netris.org \
    --cc=10519@debbugs.gnu.org \
    --cc=nisse@lysator.liu.se \
    --cc=tg@gmplib.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).