[Numpy-discussion] Args for rand and randn: call for a vote
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
Personally, I'm not that opposed to "different" calling conventions, but
I respect the opinions of the wider NumPy community.
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