On 1/22/2011 8:31 AM, Raymond Toy wrote:
> On 1/21/11 4:53 PM, Matthew Gwynne wrote:
>> Thanks all!
>>
>> On Thu, Jan 20, 2011 at 9:35 PM, Robert Dodier<robert.dodier at gmail.com> wrote:
>>> IIRC Maxima's MT implement generates chunks of 32 bits at a time,
>>> and uses those to construct the output which is some number
>>> of bits wide. For each N-bit output, Maxima uses 1 + floor(N/32) chunks.
>>> Any leftover bits are thrown away (not used for the next output).
>> Ah yes, I've found this now. Is this described in the mt19937
>> standard? Or is this simply one way out of many to do this?
> No, I don't think there's a description of how to do this in the mt19937
> docs. There is an example, I think, of how to create a 64-bit
> floating-point number from the 32-bit values, though. And cmucl
> actually only takes part of each 32-bit integer and concatenates them to
> create the larger integer. This, I think, is for historical reasons
> where the old generator produced 32-bit chunks where the least (or
> most?) significant bits were not as random as the rest.
>
> Ray
>
> _______________________________________________
> Maxima mailing list
> Maxima at math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima
Using a random number generator built in to Lisp probably has
the cost that the answer must be allocated space (put in a "box")
by the random() function. The costs associated with this can
be considerable. (Though a "clever enough" compiler might
eliminate them.) I found, in an exercise I went through
quite a few years ago (a cellular automaton simulation with
random transitions), that using random floats was a bad idea;
using random fixnums generated by an external program, stored
in an array and then used cyclically, was a major win. I think
it sped up my program by 20X. That is, 95% of the original
program was spent in random number generation.
I see that the paper was never even posted, so I just updated it
slightly and posted it as
http://www.cs.berkeley.edu/~fateman/papers/cashort.pdf
RJF