unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Mikael Djurfeldt <djurfeldt@nada.kth.se>
Cc: Rob Browning <rlb@defaultvalue.org>
Subject: Re: Nearly finished (re)integrating GMP for bignums.
Date: Wed, 12 Feb 2003 18:34:59 +0100	[thread overview]
Message-ID: <xy77kc52yik.fsf@nada.kth.se> (raw)
In-Reply-To: <87r8adihxe.fsf@zagadka.ping.de> (Marius Vollmer's message of "12 Feb 2003 17:26:37 +0100")

Marius Vollmer <mvo@zagadka.de> writes:

>> With respect to random.c, we have a pluggable random number system,
>> and ATM the bignum randoms are computed using the
>> "get_32_random_bits()" function provided by the random state object.
>> However GMP has its own random number generators, including ones for
>> bignums.  Any thoughts on how we should handle this?
>
> I think we should use the GMP generators unless they are not as good
> as ours.  But I doubt that.

This is actually a little tricky.  I'd like to bring up two points
about this issue:

1. Marius, do you suggest to use the GMP generators as a source of
   random bits for random.c, that is to "plug in" the GMP generator as
   a replacement for scm_i_uniform32?

   That would be OK, but using scm_i_uniform32 "in parallel" with the
   GMP generators would probably not be.

   It is a dangerous mistake to use multiple pseudo-random generators
   within the same application, the reason being that while each
   generator on its own will have an extremely long cycle in its
   number series, interference between the series can give
   deterministic behavior.  For example, the difference between the
   outputs of two generators might have a short cycle.  Interference
   can occur in any number of strange ways if two generators
   simultaneously affect the same program.

2. What do you mean by a "good" RNG?  I'd say it is good if it is
   fast.  Our generator is fast.  Can you name any single other
   criterion which is not "religious" and which our generator doesn't
   fulfil?  (I'm talking about something measurable here.)

   I'm no expert in RNG:s, but when doing research before writing
   random.c I couldn't find any arguments against using the current
   MWC generator.  As stated in a commentary in random.c, it has a
   cycle length of 4.6e18 and passes all tests in the "DIEHARD" RNG
   test suite.  At any rate, it should be sufficient for standard
   Guile use.

   (For those doubting the utility of speed in a RNG, I can only note
   that for me it's very important.  In my simulation software I often
   generate large random matrices and need to have multiple sources of
   simulated "noise".)

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?

Mikael


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


  parent reply	other threads:[~2003-02-12 17:34 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-02-12 16:07 Nearly finished (re)integrating GMP for bignums Rob Browning
2003-02-12 16:26 ` Marius Vollmer
2003-02-12 17:32   ` Rob Browning
2003-02-12 17:34   ` Mikael Djurfeldt [this message]
2003-02-12 18:57     ` Rob Browning
2003-02-12 21:13     ` Rob Browning
2003-02-12 23:00     ` Kevin Ryde
2003-02-27  5:11     ` Rob Browning
2003-03-03 13:13       ` Mikael Djurfeldt
2003-03-03 13:21         ` Mikael Djurfeldt
2003-03-06 17:31         ` Rob Browning
2003-03-06 18:13           ` Mikael Djurfeldt

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=xy77kc52yik.fsf@nada.kth.se \
    --to=djurfeldt@nada.kth.se \
    --cc=rlb@defaultvalue.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).