It is faster than the JMT Mersenne Twister implementation, but significantly slower than native random number generators provided by major Common Lisp implementations. For light use this shouldn't be a problem, since it is still very fast.
It should be very stable, since it's based on stable CMUCL code. It has been tested on CMUCL, SBCL, (LispWorks), Allegro CL, GCL, CLISP, and Corman Lisp. MT19937 is in the public domain.
What's the point?
Why, you might ask, would you want to use a portable, slower random number generator? The answer is consistency. The portable version of this code was originally created for Maxima, a computer algebra system. They wanted the results of the random number generator to be portable across several implementations and platforms, so that if you used a certain seed on CMUCL the numbers generated would be the same as you would get with the same seed on GCL or CLISP. This was more important than achieving the maximum possible speed. You may have similar problems.Usage
MT19937 is a plug-in replacement for the Common Lisp random-number generator. The MT19937 package exports all the Common Lisp symbols related to random number generation, so you just need to load MT19937 and call its functions instead of the built-in ones. For example:
;; Load MT19937
(asdf:oos 'asdf:load-op :mt19937)
;; Make random numbers with your implementation's random number generator.
(random 1234567)
(random 42.56)
(random 3.1415d0)
;; Make random numbers using MT19937
(mt19937:random 1234567)
(mt19937:random 42.56)
(mt19937:random 3.1415d0)
;; MT19937 has its own random state
(eq *random-state*
mt19937:*random-state*) => nil
Download
MT19937 can be downloaded from the asdf-packaging home page.
Bug
This code has a bug in the definition of the "random" compiler macro at the bottom of the file. Because it is a macro the default value for the state argument needs a quote in front of it, so that the macro argument gets bound to a symbol, not the value of a symbol.Without this fix, code calling mt19937:random with a constant argument probably won't compile at all (it would not on ACL 8.0) for lack of a make-load-form method for random-state's. If one is added so that it compiles, it will behave differently than expected: calls using constant arguments with no state argument will fail to use the dynamic value of *random-state* at the time of the call.
The macro definition should read
(define-compiler-macro random (&whole form arg &optional (state '*random-state*)with single quote added in front of *random-state*.
Or it might be safest to delete this macro entirely.
Another weakness is that it is very unclear how to contact a maintainer of the code to correct a bug like this, short of modifying this page!
Confirmed on SBCL 1.0.29. I believe the asdf-packaging mailing list is probably the best place to report the bug. I have asked on the list but have not yet received a response. -- Elliott Slaughter 2010-01-05
Update: As of 2011-01-30, this bug has finally been fixed. -- Elliott Slaughter