[Numpy-discussion] Re: Numeric.transpose (incorrect documentation)

Tim Hochberg tim.hochberg at ieee.org
Fri Jul 27 19:48:22 EDT 2001


From: "Paul F. Dubois" <paul at pfdubois.com>
> I will try to put a note in the transpose section if there isn't one there
> already. As noted, there are numerous reference-instead-of-a-copy returns
in
> Numeric which reflect the speed rather than safety orientation of the
> original designer. Many complaints of this nature are a complaint about
that
> choice, which made a package that was harder to understand and more
> difficult to use safely but which is about as fast as possible. I didn't
> like some of these choices but then again I didn't do the work.

Hmmm....

I tend to think that the reference semantics were the right choice, at least
for the lower level C implementation, since it's relatively easy to build
copy semantics on top of reference semantics, but not vice versa (except,
perhaps for slicing). Even now it would be pretty easy to build a pure
python ncNumeric[1], where copy was the default. One could even make
transpose do something sensible:

import ncNumeric as ncn

# C is a contiguous array
# N is a noncontiguous array

# Both of these would return a transposed copy
ncn.transpose(C)
ncn.transpose(N)

# This returns a transposed reference
ncn.transpose(C, copy=0)
# And this raises an exception.
ncn.transpose(N, copy=0)

That'd be kinda cool.

-tim

[1] nc for nonconfusing. I thought about using 'safe', but Numeric is
unlikely to ever be remotely safe....







More information about the NumPy-Discussion mailing list