numpy-discussion

[Numpy-discussion] rand argument question

[Sven S. <sve...@gm...>]

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]])
>>>

Re: [Numpy-discussion] rand argument question

[Robert K. <rob...@gm...>]

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

Re: [Numpy-discussion] rand argument question

[Alan G I. <ai...@am...>]

On Fri, 02 Jun 2006, Sven Schreiber apparently wrote:=20
> why doesn't rand accept a shape tuple as argument?  I find=20
> the difference between the argument types of rand and (for=20
> example) zeros somewhat confusing.  ... Can anybody offer=20
> an intuition/explanation?=20

Backward compatability, I believe.  You are not alone in=20
finding this odd and inconsistent.  I am hoping for a change=20
by 1.0, but I am not very hopeful.

Robert always points out that if you want the consistent=20
interface, you can always import functions from the 'random'=20
module.  I have never been able to understand this as=20
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=20
  an int so aesthetically objectionable that its ugliness=20
  outweighs the benefits users might get from access to=20
  a more consistent interface

This is one place where I believe a forward looking (i.e.,=20
think about new users) vision would force a small change in=20
these *convenience* functions that will have payoffs both in=20
ease of use and in eliminating this recurrent question from=20
discussion lists.

Cheers,
Alan Isaac

Re: [Numpy-discussion] rand argument question

[Robert K. <rob...@gm...>]

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

Re: [Numpy-discussion] rand argument question

[Alan G I. <ai...@am...>]

On Fri, 02 Jun 2006, Robert Kern apparently wrote:=20
> Changing the API of rand() and randn() doesn't solve any=20
> problem. Removing them might.=20

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=20
interface.

I would also be fine with demoting these to the Numeric=20
compatability module, although I find that the inferior=20
choice (since it means a loss of convenience).

Unless one of these changes is made, new users will=20
**forever** be asking this same question.  And either way,=20
making the sacrifices needed for greater consistency seems=20
like a good idea *before* 1.0.

Cheers,
Alan

Re: [Numpy-discussion] rand argument question

[Robert K. <rob...@gm...>]

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

Re: [Numpy-discussion] rand argument question

[Alan G I. <ai...@am...>]

>> On Fri, 02 Jun 2006, Robert Kern apparently wrote:=20
>>> Changing the API of rand() and randn() doesn't solve any=20
>>> problem. Removing them might.


> Alan G Isaac wrote:=20
>> I think this is too blunt an argument.  For example,=20
>> use of the old interface might issue a deprecation warning.=20
>> This would make it very likely that all new code use the new=20
>> interface.=20


On Fri, 02 Jun 2006, Robert Kern apparently wrote:=20
> My point is that there is no need to change rand() and randn() to the "ne=
w"=20
> interface. The "new" interface is already there: random.random() and=20
> random.standard_normal().=20


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.

Re: [Numpy-discussion] rand argument question

[Robert K. <rob...@gm...>]

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

Re: [Numpy-discussion] rand argument question

[Sven S. <sve...@gm...>]

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