[Numpy-discussion] Args for ones, zeros, rand, eye, ones, empty (possible 1.0 change?)
Chris.Barker at noaa.gov
Mon Jul 3 13:30:20 CDT 2006
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).
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)
> Consistency is already lost because 1d case allows both ones(5) and
> ones() (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().
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.
Christopher Barker, Ph.D.
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
More information about the Numpy-discussion