[Numpy-discussion] Counting array elements
strang at nmr.mgh.harvard.edu
Mon Oct 25 10:38:01 CDT 2004
>> I completely agree with this ... an efficient flat/ravel would seem to
>> solve many of the issues being raised. Forgive the potentially naive
>> question here, but is there any reason such an efficient, enhanced view
>> can't be implemented for the .flat method?
> I believe it is not possible without copying data. The strides between
> elements of a noncontiguous array are not always the same, so you cannot
> efficiently view it as a 1D array.
And it gets even worse for different-stride slices of N-D arrays (though
I'm not yet ready to say it's impossible to do without copying). Maybe
it's just me, but it does seem somewhat non-pythonic for a function/method
to break for an inefficient case, instead of dropping back to less
efficient (i.e., copying) behavior.
> Functions should be coded in the first place to take multi-dimensional nature
> into account in my opinion. One of the points of numarray is that it is
> multi-dimensional. If a function can work over multiple dimensions, but it
> only works for 1D arrays, it is broken in my opinion. In my opinion sum()
> _is_ broken, and introducing a separate sum_all() is an ugly hack.
+1. ;-) Hence the thought to make flattening a single "enhanced"
method/fcn ... to essentially eliminate the need for such ugly hacks.
Typically, my functions accept N-D arguments, and can operate over a
user-selected subset of these dimensions. I may pass a whole array, or
every other column, or whatever. Judging from the history of this thread,
I think a .flat that is as-efficient-as-possible and also robust to all
forms of non-contiguity would benefit many, while also reducing the
learning-curve issues associated with .flat vs ravel().
As for where/when/how to introduce .newandimprovedflat, welllllll, that's
for another thread. ;-)
Gary Strangman, PhD | Director, Neural Systems Group
Office: 617-724-0662 | Massachusetts General Hospital
Fax: 617-726-4078 | 149 13th Street, Ste 10018
| Charlestown, MA 02129
More information about the Numpy-discussion