Hi all, this may be a stupid question, but why doesn't rand accept a shape tuple as argument? I find the difference between the argument types of rand and (for example) zeros somewhat confusing. (See below for illustration.) Can anybody offer an intuition/explanation? (This is still on 0.9.6 because of matplotlib compatibility.) Thanks much, Sven
import numpy as n n.rand((3,2)) Traceback (most recent call last): File "<interactive input>", line 1, in ? File "mtrand.pyx", line 433, in mtrand.RandomState.rand File "mtrand.pyx", line 361, in mtrand.RandomState.random_sample File "mtrand.pyx", line 131, in mtrand.cont0_array TypeError: an integer is required n.zeros((3,2)) array([[0, 0], [0, 0], [0, 0]]) n.zeros(3,2) Traceback (most recent call last): File "<interactive input>", line 1, in ? TypeError: data type not understood n.rand(3,2) array([[ 0.27017528, 0.98280906], [ 0.58592731, 0.63706962], [ 0.74705193, 0.65980377]])
Sven Schreiber wrote:
Hi all, this may be a stupid question, but why doesn't rand accept a shape tuple as argument? I find the difference between the argument types of rand and (for example) zeros somewhat confusing. (See below for illustration.) Can anybody offer an intuition/explanation?
rand() is a convenience function. It's only purpose is to offer this convenient API. If you want a function that takes tuples, use numpy.random.random(). -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco
On Fri, 02 Jun 2006, Sven Schreiber apparently wrote:
why doesn't rand accept a shape tuple as argument? I find the difference between the argument types of rand and (for example) zeros somewhat confusing. ... Can anybody offer an intuition/explanation?
Backward compatability, I believe. You are not alone in finding this odd and inconsistent. I am hoping for a change by 1.0, but I am not very hopeful. Robert always points out that if you want the consistent interface, you can always import functions from the 'random' module. I have never been able to understand this as a response to the point you are making. I take it the core argument goes something like this: - rand and randn are convenience functions * if you do not find them convenient, don't use them - they are in wide use, so it is too late to change them - testing the first argument to see whether it is a tuple or an int so aesthetically objectionable that its ugliness outweighs the benefits users might get from access to a more consistent interface This is one place where I believe a forward looking (i.e., think about new users) vision would force a small change in these *convenience* functions that will have payoffs both in ease of use and in eliminating this recurrent question from discussion lists. Cheers, Alan Isaac
Alan G Isaac wrote:
On Fri, 02 Jun 2006, Sven Schreiber apparently wrote:
why doesn't rand accept a shape tuple as argument? I find the difference between the argument types of rand and (for example) zeros somewhat confusing. ... Can anybody offer an intuition/explanation?
Backward compatability, I believe. You are not alone in finding this odd and inconsistent. I am hoping for a change by 1.0, but I am not very hopeful.
Robert always points out that if you want the consistent interface, you can always import functions from the 'random' module. I have never been able to understand this as a response to the point you are making.
I take it the core argument goes something like this: - rand and randn are convenience functions * if you do not find them convenient, don't use them - they are in wide use, so it is too late to change them - testing the first argument to see whether it is a tuple or an int so aesthetically objectionable that its ugliness outweighs the benefits users might get from access to a more consistent interface
My argument does not include the last two points. - They are in wide use because they are convenient and useful. - Changing rand() and randn() to accept a tuple like random.random() and random.standard_normal() does not improve anything. Instead, it adds confusion for users who are reading code and seeing the same function being called in two different ways. - Users who want to see numpy *only* expose a single calling scheme for top-level functions should instead ask for rand() and randn() to be removed from the top numpy namespace. * Backwards compatibility might prevent this.
This is one place where I believe a forward looking (i.e., think about new users) vision would force a small change in these *convenience* functions that will have payoffs both in ease of use and in eliminating this recurrent question from discussion lists.
*Changing* the API of rand() and randn() doesn't solve any problem. *Removing* them might. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco
On Fri, 02 Jun 2006, Robert Kern apparently wrote:
Changing the API of rand() and randn() doesn't solve any problem. Removing them might.
I think this is too blunt an argument. For example, use of the old interface might issue a deprecation warning. This would make it very likely that all new code use the new interface. I would also be fine with demoting these to the Numeric compatability module, although I find that the inferior choice (since it means a loss of convenience). Unless one of these changes is made, new users will **forever** be asking this same question. And either way, making the sacrifices needed for greater consistency seems like a good idea *before* 1.0. Cheers, Alan
Alan G Isaac wrote:
On Fri, 02 Jun 2006, Robert Kern apparently wrote:
Changing the API of rand() and randn() doesn't solve any problem. Removing them might.
I think this is too blunt an argument. For example, use of the old interface might issue a deprecation warning. This would make it very likely that all new code use the new interface.
My point is that there is no need to change rand() and randn() to the "new" interface. The "new" interface is already there: random.random() and random.standard_normal(). -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco
On Fri, 02 Jun 2006, Robert Kern apparently wrote:
Changing the API of rand() and randn() doesn't solve any problem. Removing them might.
Alan G Isaac wrote:
I think this is too blunt an argument. For example, use of the old interface might issue a deprecation warning. This would make it very likely that all new code use the new interface.
On Fri, 02 Jun 2006, Robert Kern apparently wrote:
My point is that there is no need to change rand() and randn() to the "new" interface. The "new" interface is already there: random.random() and random.standard_normal().
Yes of course; that has always been your point. In an earlier post, I indicated that this is your usual response. What your point does not addres: the question about rand and randn keeps cropping up on this list. My point is: numpy should take a step so that this question goes away, rather than maintain the status quo and see it crop up continually. (I.e., its recurrence should be understood to signal a problem.) Cheers, Alan PS I'll shut up about this now.
Alan G Isaac wrote:
On Fri, 02 Jun 2006, Robert Kern apparently wrote:
My point is that there is no need to change rand() and randn() to the "new" interface. The "new" interface is already there: random.random() and random.standard_normal().
Yes of course; that has always been your point. In an earlier post, I indicated that this is your usual response.
What your point does not addres: the question about rand and randn keeps cropping up on this list.
My point is: numpy should take a step so that this question goes away, rather than maintain the status quo and see it crop up continually. (I.e., its recurrence should be understood to signal a problem.)
I'll check in a change to the docstring later today. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco
Robert Kern schrieb:
My point is that there is no need to change rand() and randn() to the "new" interface. The "new" interface is already there: random.random() and random.standard_normal().
Ok thanks for the responses and sorry for not searching the archives about this. I tend to share Alan's point of view, but I also understand that it may be too late now to change the way rand is called. -Sven
participants (3)
-
Alan G Isaac -
Robert Kern -
Sven Schreiber