[ruby-talk:4549] Re: RFC: Ruby extension for Random numbers

Gyu Decoux writes:

> Why not RNG (or Rng), you make always reference to RNG in the
>documentation. 
>
Our feeling is that matz and others have tried not to use acronyms in the
standard Ruby libs and since Random might be a "standard" component we
wanted to keep with that spirit.

> an alias for lrand, perhaps ?
>
I guess you want lrand alias for rand_fixnum? Is there some clever way to
actually return a 32-bit value in Ruby? We've contemplated using Bignums
or 4-char strings but I guess is a general problem that might be an issue
in other Ruby extensions: If you want to "port" algs from C that are heavy
on 32-bit arithmetic there's no simple way to do it in Ruby. Or is it?
(concrete example: Many crypto algs need lots of random numbers, and they
frequently use 32-bit unsigned ints. How to simply transfer them via
Ruby?)

I guess you can easily make a class for 32 bit nums but maybe there should
be a standard way?!

> why this initial underscore `_', why not load(), dump()
>
Because of dev.rubycentral.com's description of Marhal:

If your class has special serialization needs (for example you want to
serialize in some specific format), or if it contains objects that would
otherwise not be serializable, you can implement your own serialization
strategy by defining two methods, _dump and _load: 

Method type Signature Returns 
Instance _dump(aDepth) Returns a String 
Class _load(aString) Returns a reconstituted Object 
 
The instance method _dump should return a String object containing all the
information necessary to reconstitute objects of this class, and all
referenced objects up to a maximum depth of aDepth (a value of -1 should
disable depth checking). The class method _load should take a String and
return an object of this class.


> Mersenne Twister is known as MT19937 (mt19937-1.c, mt19937-2.c, and 
> also ... cokus.c :-))
>
See above on the reason for "full"/long names. We plan on giving both full
and short names in the lib.

R> class RandomGauss

> Difficult to say for this class, because it exist many distribution
> (i.e. not only the gaussian distribution) (cauchy, rayleigh, pareto,
>etc)
>  and perhaps we will end with 50 classes
>
Yes, my idea was actually to have a class for each distribution. Would you
prefer (module-level) methods taking a RNG and the distribution-specific
parameters? My idea was that there might be a small performance penalty to
the latter scheme in case you need a lot of samples from a distribution
(say in a simulation).

I only included Gaussian in the design since the other distrs are pretty
much the same.

/Robert