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
From: "Paul F. Dubois" <paul@pfdubois.com> 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....