Re: Numeric.transpose (incorrect documentation)

"Curtis Jensen" <cjensen@bioeng.ucsd.edu> wrote in message news:3B6076D4.68B6840C@bioeng.ucsd.edu...
the documenation for the "transpose" function for the "Numeric" module seems to be incoorect, or at least missleading.
The correct place for this is probably the numpy-discussion list, so I'm cc'ing it there. Perhaps the Paul Dubois will see it and have some ideas for clearing of the docs.
It's been a while since I looked at the NumPy docs, so I don't recall what conventions they use here. However, transpose does return a new array, it just points to the same data as the original. If a=transpose(b), "a is b" is false and "a.shape == b.shape" is false, so clearly they are different objects (i.e., different arrays). You know most of this, as you demonstrate down below, I just wanted to make the point that there is a difference between a new array and new data. Note that nearly every operation that can return a reference rather than a copy does so. Even slicing, if b=a[3:5], then 'b' holds a reference to the same data as 'a'. Some functions go so far to return a reference when they can, but otherwise copy. See ravel for example -- it copies the data if its argument is not contiguous, otherwise it uses a reference. Now _that_ can be confusing! Useful though. -tim

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. -----Original Message----- From: numpy-discussion-admin@lists.sourceforge.net [mailto:numpy-discussion-admin@lists.sourceforge.net]On Behalf Of Tim Hochberg Sent: Thursday, July 26, 2001 1:35 PM To: numpy-discussion@lists.sourceforge.net Subject: [Numpy-discussion] Re: Numeric.transpose (incorrect documentation) "Curtis Jensen" <cjensen@bioeng.ucsd.edu> wrote in message news:3B6076D4.68B6840C@bioeng.ucsd.edu...
the documenation for the "transpose" function for the "Numeric" module seems to be incoorect, or at least missleading.
The correct place for this is probably the numpy-discussion list, so I'm cc'ing it there. Perhaps the Paul Dubois will see it and have some ideas for clearing of the docs.

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

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. -----Original Message----- From: numpy-discussion-admin@lists.sourceforge.net [mailto:numpy-discussion-admin@lists.sourceforge.net]On Behalf Of Tim Hochberg Sent: Thursday, July 26, 2001 1:35 PM To: numpy-discussion@lists.sourceforge.net Subject: [Numpy-discussion] Re: Numeric.transpose (incorrect documentation) "Curtis Jensen" <cjensen@bioeng.ucsd.edu> wrote in message news:3B6076D4.68B6840C@bioeng.ucsd.edu...
the documenation for the "transpose" function for the "Numeric" module seems to be incoorect, or at least missleading.
The correct place for this is probably the numpy-discussion list, so I'm cc'ing it there. Perhaps the Paul Dubois will see it and have some ideas for clearing of the docs.

From: "Paul F. Dubois" <paul@pfdubois.com> that
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....
participants (2)
-
Paul F. Dubois
-
Tim Hochberg