Re: Nearly finished (re)integrating GMP for bignums.

[Rob Browning <rlb@defaultvalue.org>]

Mikael Djurfeldt <djurfeldt@nada.kth.se> writes:

> Ideally, the bignum code would use the pluggable source of random bits
> in random.c and the GMP generators would be provided as optional
> plugins for random.c.  Rob, is this possible?

The main issue I have now is that in scm_c_random_bignum, the code
directly manipulates the old bignum internals.  So I'll need to
convert that to GMP. i.e.:

  LONG32 *bits, mask, w;
  nd = SCM_NUMDIGS (m);
  /* calculate mask for most significant digit */
#if SIZEOF_INT == 4
  /* 16 bit digits */
  if (nd & 1)
    {
      /* fix most significant 16 bits */
      unsigned short s = SCM_BDIGITS (m)[nd - 1];

To be sure have the details right -- SCM_NUMDIGS gives the number of
elements in SCM_BDIGITS, where the last element is the most
significant digit right?

I'll need to figure out how this should map onto the available GMP
operations.  Right now I don't expose much from numbers.c
"bignum-wise", but I'm thinking of adding some _i_ functions that map
onto gmp operations, and would probably also be appropriate for any
other bignum implementation, i.e.:

  void scm_i_bigadd_ui (SCM dest, SCM src, unsigned long n);
  void scm_i_bigsub_ui (SCM dest, SCM src, unsigned long n);
  void scm_i_bigneg (SCM dest);

etc.  These prototypes follow the GMP calling convention which can be
convenient since it allows you to express both "in-place"
modifications where dest == src, or copy operations where dest != src.
The ability to do "in-place" operations can be important when dealing
with large bignums because you don't necessarily want to have to
allocate a new bignum for each operation.

Alternately, I could just support in-place operations:

  void scm_i_bigadd_ui (SCM big, unsigned long n);

or I could only support our more traditional "always copy on write"
style operations:

  SCM scm_i_bigadd_ui (SCM big, unsigned long n);

The whole point of the scm_i_big* functions would be for use by other
parts of guile where the code needs to operate directly on bignums.

The alternative is to just expect the other code use SCM_I_BIG_MPZ(x),
to get hold of the mpz_t value and then manipulate that directly.  The
direct approach could be faster, and gives more flexibility, but of
course it's less portable (presuming we ever change our bignum
implementation again).

In truth, ATM we don't have that much code outside numbers.c that
manipulates bignums directly.  Aside from the GC and eq, it's mostly
random.c and socket.c so far.  So it may not be a big deal either way.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel