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

Faheem Mitha faheem at email.unc.edu
Tue Oct 5 18:41:02 CDT 2004


On Tue, 5 Oct 2004, Perry Greenfield wrote:

> I'm not sure I understand what you want to do. Do you want to link 
> directly to the extension code from your C++ code?

Yes.

> If so I'm wondering why. It would make the most sense if the C++ code 
> needed obtain small numbers of random numbers in some iterative loop, 
> and you wish to use the same random number library that that numarray is 
> using.

I need to obtain an arbitrary (not known in advance) number of random 
numbers in the C++ code.

I'm thinking of using the same random number library mostly because I 
assumed that using the same seed across the python/C interface would be 
supported. This is how it works in R (the only other place I have used 
this). Also, I had been using the same routines in the Python code I'm 
trying to convert to C++, so it would be a relatively smooth transfer.

If I was to use a pure C/C++ library, I'd have to worry about copying the 
seed back and forth between Python and C. Is this what I'll have to do 
then?

> Otherwise, I would normally obtain the random number array in python, 
> then call the C++ extension.

Yes, this is what everyone suggests. But in my case, the number of random 
variates required is not known in advance. I get the feeling this 
situation does not arise very often for most people, but I work with 
stochastic processes which terminate according to some stopping criterion, 
and that is the standard situation in this case.

Also generating these numbers in Python would give rise to serious 
performance issues.

> Perhaps I didn't read carefully enough. Normally linking to an extension 
> module involves some hacks that I'm not sure were done for the 
> randomarray module (the gory details are in the python docs for 
> extension modules), Todd can check on that, I'm not sure I will have 
> time (a superficial check seems to indicate that it doesn't support 
> direct linking, though one could link to the underlying library I 
> suppose).

Hmm. Well, this is unwelcome news. You mean I cannot link to ranlib.so? I 
assumed that including the ranlib.h header and linking my C++ module 
against ranlib.so would be enough. I suppose that was too optimistic.

> As an aside, it is likely that a better module can be done as some
> have suggested, we just took what Numeric had at the time. Doing that
> is not a high priority with us at the moment (anyone else want to
> tackle that?). Right now integration with scipy is our biggest
> priority so things like this will have to take a back seat for
> a while.

> Furthermore, we did what we needed to to port these modules from
> Numeric, but that didn't necessarily make us experts in how they
> worked. I wish we were, but we've generally been directing our
> energy elsewhere. I'd presume that the sensible way for the module
> to work is to initialize its seed from a time-based seed in the
> absence of any other seed initialization, and to keep the seed
> state in the extension module, but I could be wrong.

Yes. That is how R does it, anyway. Specifically, you declare the seed 
static, and then it persists across the Python/C interface. That is what I 
thought you had in the numarray code. Would it be hard to make it work 
like this?

I'm no expert either.

                                                             Faheem.




More information about the Numpy-discussion mailing list