[Numpy-discussion] Re: Numeric3 PEP
Tim Hochberg
tim.hochberg at cox.net
Sat Feb 19 15:10:14 EST 2005
Hi Travis,
First off, let me say that I'm encouraged to see some action towards
unifying Numeric/Numarray the split has been somewhat dismaying. Thank
you for your efforts in this regard.
I'd like to lobby against flatten(), r() and i(). To a large extent,
these duplicate the functionality of flat, real and imag. And, these
three methods are defined to sometimes return copies and sometimes
return views. That type of interface is a recipe for errors and should
only be used as a last resort. Fortunately in this case there are better
alternatives.
Flatten() is not necessary now that flat will be faux array with a view
to the original [I believe you are calling it an indexable iterator]. I
would, however, recomend that A.flat.copy() work. In that case, A.flat
would be used when no copy was desired, and A.flat.copy() when a copy
was desired. I don't find the copy when discontiguous case useful
enough to deserve it's own function and it's error prone as I'll discuss
more below.
r() appears to be around just for symmetry with i() since A.r() will
always be the same as A.real. That leaves i(). My opinion is that this
case would be better served by returning a read-only array of zeros when
operating on a real array. This array could even be a faux-array that
doesn't allocate any space, although that may be a project for another day.
If it's really deemed necessary to have these functions in addition to
their attribute brethren, I recomend that they always return copies
rather than varying their behaviour depending on the situation. The
problem with methods that sometimes return a copy, is that it won't be
long before someone types:
def foobar(a)
flat_view = a.flatten()
# lots of code
flat_view[some_index] = some_new_number
This works until someone passes in a discontiguous array, at which point
it fails mysteriously. This type of problem tends to be somewhat
resistant to unit tests, since tests often involve only contiguous arrays.
Regards,
-tim
More information about the NumPy-Discussion
mailing list