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

Bruce Southey southey at uiuc.edu
Wed Oct 6 07:01:38 CDT 2004


Hi,  
My understanding is that you can use the Ranlib, R math, and GNU Scientific  
libraries in the manner you suggest or directly include the random number 
generator in your code. Usually you define the seed that should provide the 
same psuedo-random number stream every time these are used. If you don't use a 
seed then it is usually impossible to get the same stream of psuedo-random 
numbers. So I do not understand what you need to keep the same random number 
state. Not to mention that the common generators do repeat, some sooner than 
others. 
  
In your response to Perry, you indicate that you do not need an array of 
random numbers but rather the stream of random numbers. This is very different 
and I think you need to refine your algorithm to identify what parts need to 
be C/C++ and what need to be in Python/numarray. Since you currently have 
Python code, I would profile it to see what parts actually need extending - 
some times Python is rather surprising on how quick some things can be done 
(like using dictionaries). Providing those parts may be more fruitful to you 
than my vague responses. 
 
Regards 
Bruce 
  
---- Original message ----  
>Date: Tue, 5 Oct 2004 18:43:48 -0400 (EDT)  
>From: Faheem Mitha <faheem at email.unc.edu>    
>Subject: Re: [Numpy-discussion] numarray.random_array number generation in C  
code    
>To: Bruce Southey <southey at uiuc.edu>  
>Cc: numpy-discussion <numpy-discussion at lists.sourceforge.net>  
>  
>  
>  
>On Tue, 5 Oct 2004, Bruce Southey wrote:  
>  
>> Hi,  
>> It is rather hard to suggest anything without more detail on what you want  
to  
>> actually do.  
>  
>I could give you more details if you were interested.  
>  
>> 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.  
>  
>Not really. One might (and I frequently do) want to run the same function   
>(which in this case might be all in C++ code), interactively with   
>different parameters. The kind of thing that I'm doing is akin to   
>exploratory data analysis, and the specific code in question is a   
>stochastic search algorithm. Doing all this in C++ would not be very   
>interactive. Also, one often wants to postprocess data output using Python   
>scripts. This involves multiple calls to C++ code, and would be impossible   
>to do using C++, since one has to call other Python libraries.  
>  
>  > I see at least three options:  
>  
>> 1) Do everything in Python/numarray.  
>  
>That's my current situation.  
>  
>> 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.  
>  
>This doesn't work very well unless you know in advance how many random   
>numbers are needed (not the case, for example, for stochastic search   
>algorithms), and in any case is a rather clumsy way to do things. No   
>offense intended.  
>  
>> 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.  
>  
>Yes, but part of the point of mixed programming is that you have an   
>interpreted front end which can easily hook into other routines. Also, in   
>this case, you would not be passing the seed in, since there is nothing to   
>pass it in from. One would simply call system time or something similar to   
>obtain the seed.  
>  
>> You can email me privately if you want.  
>  
>I'll keep sending this to the list unless someone objects, since I think   
>this is of some general interest.  
>  
>Really, my main question was to whether my understanding of how to use the   
>Numarray random number facilities in C was correct or not.  
>  
>                                                                Faheem.  
  
 




More information about the Numpy-discussion mailing list