[Numpy-discussion] Args for ones, zeros, rand, eye, ones, empty (possible 1.0 change?)

[Christopher Barker]

Tim Hochberg wrote:
> I also find:
> 
>   ones([5, 5], dt)
> 
> clearer than:
> 
>    ones(5, 5, dt)
> 
> or, more dramatic, consider: ones([dx, dy], dt) versus ones(dx, dy, dt). 
> Brrrr!

And I imagine this is EXACTLY why Numeric was originally designed that 
way: when there are more arguments to pass, then a shape is essentially 
a single entity. Also consider this:

MyShape = a.shape

b = ones(MyShape, N.float_)

much better than:

b = ones(*MyShape, N.float_)

At least I think so.

> Kahan is oft quoted by Tim Peters who seems to have one of the better 
> grasps of the fiddly aspects of floating point in the Python community, 
> so I give his views a lot of weight.

I took at class with Kahan at Berkeley (that I barely passed), he is 
definitely someone to listen to.

> NumPy really has at 
>> least two "users"  1) application developers and 2) prototype developers 

FWIW: I came from a heavy MATLAB background, still do far more 
prototyping that really application writing (though I certainly do the 
later), and I want:

>> 1) longish_explanatory names
>> 2) consistent calling syntax
(note that I've edited those a bit...)

And above all:
>> 3) strict name-space control

In my experience that that is a difference between "prototyping" and 
"using Python like Matlab". The sooner that you learn to use Python like 
Python, rather than trying to use it like Matlab, the better off you'll 
be. Python is an excellent language for prototyping, but even for that, 
you're better off working with, rather than against, its features.

As for the current issue:

1) Make everything take a sequence for the size argument.
2) dump the "convenience functions" into a compatibility module.

Is it so hard to write:

import numpy.random.uniform as rand

(though I notice that numpy.random.rand() is the inconsistent 
"convenience function" -- darn)


Sasha wrote:
> Consistency is already lost because 1d case allows both ones(5) and
> ones([5]) (and even ones((5,)) if anyone can tolerate that
> abomination).  I don't think those who argue for sequence only are
> willing to require ones([5]).

But I'd be happy to ban ones(5) (by the way, doesn't Matlab's ones(5) 
produce a 5X5 matrix?). We certainly don't' want to require a list, that 
would totally go against Python's concept of duck typing.



-Chris




-- 
Christopher Barker, Ph.D.
Oceanographer
                                     		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov