[Rd] user supplied random number generators

[Christophe Dutang]

Hello,

Le 30 juil. 09 à 08:21, Ross Boylan a écrit :

> ?Random.user says (in svn trunk)
>  Optionally,
>  functions \code{user_unif_nseed} and \code{user_unif_seedloc} can be
>  supplied which are called with no arguments and should return  
> pointers
>  to the number of seeds and to an integer array of seeds.  Calls to
>  \code{GetRNGstate} and \code{PutRNGstate} will then copy this array  
> to
>  and from \code{.Random.seed}.
> And it offers as an example
>  void  user_unif_init(Int32 seed_in) { seed = seed_in; }
>  int * user_unif_nseed() { return &nseed; }
>  int * user_unif_seedloc() { return (int *) &seed; }
>
> First question: what is the lifetime of the buffers pointed to by the
> user_unif-* functions, and who is responsible for cleaning them up?   
> In
> the help file they are static variables, but in general they might be
> allocated on the heap or might be in structures that only persist as
> long as the generator does.
>
> Since the example uses static variables, it seems reasonable to  
> conclude
> the core R code is not going to try to free them.
>
> Second, are the types really correct?  The documentation seems quite
> explicit, all the more so because it uses Int32 in places.  However,  
> the
> code in RNG.c (RNG_Init) says
>
> 	    ns = *((int *) User_unif_nseed());
> 	    if (ns < 0 || ns > 625) {
> 		warning(_("seed length must be in 0...625; ignored"));
> 		break;
> 	    }
> 	    RNG_Table[kind].n_seed = ns;
> 	    RNG_Table[kind].i_seed = (Int32 *) User_unif_seedloc();
> consistent with the earlier definition of RNG_Table entries as
> typedef struct {
>    RNGtype kind;
>    N01type Nkind;
>    char *name; /* print name */
>    int n_seed; /* length of seed vector */
>    Int32 *i_seed;
> } RNGTAB;
>
> This suggests that the type of user_unif_seedloc is Int32*, not int *.
> It also suggests that user_unif_nseed should return the number of 32  
> bit
> integers.  The code for PutRNGstate(), for example, uses them in just
> that way.
>
> While the dominant model, even on 64 bit hardware, is probably to  
> leave
> int as 32 bit, it doesn't seem wise to assume that is always the case.

You can test the size of an int with a configure script. see for  
example the package foreign, the package randtoolbox (can be found in  
Rmetrics R forge project) I maintain with Petr Savicky.

By the way, I'm sure he has an answer about RNGkind because he made  
the runif interface in the randtoolbox package and in rngWELL19937  
package.

Christophe

>
>
> I got into this because I'm trying to extend the rsprng code; sprng
> returns its state as a vector of bytes.  Converting these to a  
> vector of
> integers depends on the integer length, hence my interest in the exact
> definiton of integer.  I'm interested in lifetime because I believe
> those bytes are associated with the stream and become invalid when the
> stream is freed; furthermore, I probably need to copy them into a  
> buffer
> that is padded to full wordlength.  This means I allocate the buffer
> whose address is returned to the core R RNG machinery.  Eventually
> somebody needs to free the memory.
>
> Far more of my rsprng adventures are on
> http://wiki.r-project.org/rwiki/doku.php?id=packages:cran:rsprng.   
> Feel
> free to read, correct, or extend it.
>
> Thanks.
>
> Ross Boylan
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

--
Christophe Dutang
Ph.D. student at ISFA, Lyon, France
website: http://dutangc.free.fr