[Numpy-discussion] Args for rand and randn: call for a vote

Travis Oliphant oliphant at ee.byu.edu
Tue Jul 11 16:15:06 CDT 2006

Ed Schofield wrote:

>Last week's discussion on rand() and randn() seemed to indicate a  
>sentiment that they ought to take tuples for consistency with ones,  
>zeros, eye, identity, and empty -- that, although they are supposed  
>to be convenience functions, they are inconvenient precisely because  
>of their inconsistency with these other functions.  This issue has  
>been raised many times over the past several months.
>Travis made a change in r2572 to allow tuples as arguments, then took  
>it out again a few hours later, apparently unsure about whether this  
>was a good idea.
>I'd like to call for a vote on what people would prefer, and then ask  
>Travis to make a final pronouncement before the feature freeze.

This is my thinking about the rand and randn situation:

I really like the rand and randn functions.  I use them all the time and 
want quick and easy access to them. 

In retrospect, the rand and randn functions probably should have been 
placed in a separate "user" namespace like
pylab or numlab or something like that to distinguish it from "numpy the 

But, we don't have something like that in place at this point, so what 
to do now?

I'm opposed to any suggestion to get rid of the rand(3,3) calling 
syntax.  One reason is that I like the syntax for this function and I've 
used it a lot.  It comes from MLab in Numeric and so it is needed to 
support compatibility with Numeric as well.  So, we can't just get rid 
of it entirely.
Another big reason is that there is already a function that uses ONLY 
the tuple syntax to do exactly the same thing.  Look at the docstrings 
for rand and randn to get the names.    If you are opposed to the rand 
and randn syntax then just ignore those functions and use


So, I'm opposed to getting rid of the *args based syntax.   My feelings 
are weaker regarding adding the capability to rand and randn to accept a 
tuple.  I did test it out and it does seem feasible to add this feature 
at the cost of an additional comparison.  I know Robert is opposed to it 
but I'm not sure I understand completely why. 

Please correct me if I'm wrong, but I think it has something to do with 
making the random_sample and standard_normal functions irrelevant and 
unnecessary combined with my hypothesis that Robert doesn't like the 
*args-style syntax.  Therefore, adding support to rand and randn for 
tuples, would make them the default random-number generators and there 
would be proliferating code that was "harder to read" because of the 
different usages.

Personally, I'm not that opposed to "different" calling conventions, but 
I respect the opinions of the wider NumPy community.  

In sum: 

rand and randn have to live somewhere and accept their current calling 
convention.  I would not be opposed at this point to taking them out of 
top-level numpy and putting them instead into a "numlab" name-space (for 
lack of a better name).  However, I'm not so sure that making a "numlab" 
name-space really solves any of the issues that are being debated in 
this case.  So, I'm not going to spend any time doing it...


More information about the Numpy-discussion mailing list