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
next prev 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).