[Numpy-discussion] numarray.random_array number generation in C code

[Bruce Southey]

Hi,  
It is rather hard to suggest anything without more detail on what you want to 
actually do.  As you describe it, why do you need the 'seed' returned? It 
would only make sense if you were going in and out of Python multiple times - 
a somewhat undesirable situation due to the overhead costs.  
  
I see at least three options:  
1) Do everything in Python/numarray. 
 
2) Do parts in Python and the other in C/C++. 
   For example, pass a matrix of random numbers to your code from Python. The 
'seed' never needs to leave Python.   
 
3) Do it all in C/C++ - pass the 'seed' into your code that includes the 
random number generator(s) - there is C/C++ code around for this. Do you stuff 
and then return the 'seed' back with whatever else is required.  
  
You can email me privately if you want. 
 
Bruce 
  
   
---- Original message ----  
>Date: Sat, 2 Oct 2004 01:23:21 -0400 (EDT)  
>From: Faheem Mitha <faheem at email.unc.edu>    
>Subject: [Numpy-discussion] numarray.random_array number generation in C code    
>To: numpy-discussion <numpy-discussion at lists.sourceforge.net>  
>  
>  
>Dear People,  
>  
>I want to write some C++ code to link with Python, using the   
>Boost.Python interface. I need to generate random numbers in the C++   
>code, and I was wondering as to the best way of doing this.  
>  
>Note that it is important that the random number generation interoperate   
>seamlessly with Python, in the sense that the behavior of the calls to   
>the RNG is the same whether calls are made at the C level or the Python   
>level. I hope the reasons why this is important are obvious.  
>  
>I was thinking that the method should go like this.  
>  
>1) When C/C++ code called, reads seed from python random state.  
>  
>2) Does its stuff.  
>  
>3) Writes seed back to python level when it exits.  
>  
>After doing a little investigation of the numarray.random_array python   
>library and associated extension modules, it seems possible that the   
>answer is simpler than I had supposed. However, I would appreciate it if   
>someone would tell me if my understanding is incorrect in some places.  
>  
>Summary: It seems that I can just call all the C entry point routines   
>defined in ranlib.h, without worrying about getting or setting seeds.  
>  
>Rationale:  
>  
>The structure of this random number facility has three parts, all files in   
>Packages/RandomArray2/Src.  
>  
>1) low-level C routines: Packages/RandomArray2/Src/com.c and   
>Packages/RandomArray2/Src/ranlib.c.  
>  
>com.c: basic RNG stuff; getting and setting seeds etc.  
>ranlib.c: Random number generator algorithms for different distributions   
>etc.  
>  
>2) Python to C interface: Packages/RandomArray2/Src/ranlibmodule.c.  
>  
>This interfaces the stuff in com.c and ranlib.c.  
>  
>3) Python wrapper: Packages/RandomArray2/Lib/RandomArray2.py.  
>  
>This wraps the C interface. In most cases it does not do much else besides   
>some basic argument error checking.  
>  
>From my perspective, the important thing is that the random number seed is   
>only defined at C level as a static object, all the RNG stuff happens at C   
>level, and the Python code just calls the C code as necessary. (I'm   
>sketchy about the details of what is defined as the seed etc.)  
>  
>This is in contrast with the R RNG facility (the only other RNG facility I   
>am familiar with), which uses macros SetRNGstate() and GetRNGstate() to   
>read and write the seed, which is defined at R level.  
>  
>Therefore, the upshot is that the C routines in ranlib.h read and write   
>the same seed as the python level functions do, so no special action is   
>necessary with regard to the seed.  
>  
>Is this correct?  
>  
>In any case, it would be nice if something like the above was documented,   
>so lost souls like myself don't have to go trawling through the source   
>code to figure out what is going on. Of course it is nice that the source   
>code is available, otherwise even that would be impossible.  
>  
>R documents this stuff in the "Writing R Extensions" manual, online at   
>http://cran.r-project.org/doc/manuals/R-exts.pdf. Perhaps the Numarray   
>manual could have a small section about this too.  
>  
>                                                         Regards, Faheem.  
>  
>  
>  
>-------------------------------------------------------  
>This SF.net email is sponsored by: IT Product Guide on ITManagersJournal  
>Use IT products in your business? Tell us what you think of them. Give us  
>Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more  
>http://productguide.itmanagersjournal.com/guidepromo.tmpl  
>_______________________________________________  
>Numpy-discussion mailing list  
>Numpy-discussion at lists.sourceforge.net  
>https://lists.sourceforge.net/lists/listinfo/numpy-discussion