Hello, I imagine that perhaps this issue I'm seeing is only an issue because I don't thoroughly understand the buffer issues associated with numpy arrays, but here it is anyway: In [16]:a1 = numpy.zero numpy.zeros numpy.zeros_like In [16]:a1 = numpy.zeros( (2,2) ) In [17]:a1[0,:] = 1 In [18]:a1 Out[18]: array([[ 1., 1.], [ 0., 0.]]) In [19]:str(a1.data) Out[19]:'\x00\x00\x00\x00\x00\x00\xf0?\x00\x00\x00\x00\x00\x00\xf0?\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00' In [20]:a2 = a1.transpose() In [21]:str(a2.data) Out[21]:'\x00\x00\x00\x00\x00\x00\xf0?\x00\x00\x00\x00\x00\x00\xf0?\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00' That is, when getting the .data from an array, if it was C_CONTIGUOUS but was .transposed(), the .data does not reflect this operation, right? So, would that imply that a .copy() should be done first on any array that you want to access .data on? Thanks, Glen
Glen W. Mabey wrote:
Hello,
I imagine that perhaps this issue I'm seeing is only an issue because I don't thoroughly understand the buffer issues associated with numpy arrays, but here it is anyway:
In [16]:a1 = numpy.zero numpy.zeros numpy.zeros_like
In [16]:a1 = numpy.zeros( (2,2) )
In [17]:a1[0,:] = 1
In [18]:a1 Out[18]: array([[ 1., 1.], [ 0., 0.]])
In [19]:str(a1.data) Out[19]:'\x00\x00\x00\x00\x00\x00\xf0?\x00\x00\x00\x00\x00\x00\xf0?\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'
In [20]:a2 = a1.transpose()
In [21]:str(a2.data) Out[21]:'\x00\x00\x00\x00\x00\x00\xf0?\x00\x00\x00\x00\x00\x00\xf0?\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'
That is, when getting the .data from an array, if it was C_CONTIGUOUS but was .transposed(), the .data does not reflect this operation, right?
Correct, it just gives you the data as-is in memory, not as interpreted via the strides. Transposition and slicing are implemented by changing the strides and not changing any data.
So, would that imply that a .copy() should be done first on any array that you want to access .data on?
asarray(a, order='C') should be sufficient, I think. That shouldn't copy if it is already correctly ordered. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco
Glen W. Mabey wrote:
So, would that imply that a .copy() should be done first on any array that you want to access .data on?
Or even ascontiguousarray(). -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco
On 29/03/07, Robert Kern <robert.kern@gmail.com> wrote:
Glen W. Mabey wrote:
So, would that imply that a .copy() should be done first on any array that you want to access .data on?
Or even ascontiguousarray().
I'd like to point out that the numpy usage of the word "contiguous" is a bit misleading: while naively one would expect it to mean that the data were contiguous in memory, what it actually means is that they are contiguous and the indexing is C-ordered: In [7]: a = arange(5) In [8]: a.flags["CONTIGUOUS"] Out[8]: True In [9]: a[::-1].flags["CONTIGUOUS"] Out[9]: False In [10]: eye(2).flags["CONTIGUOUS"] Out[10]: True In [11]: transpose(eye(2)).flags["CONTIGUOUS"] Out[11]: False There's no help for it now, I suppose. Anne
On 3/29/07, Anne Archibald <peridot.faceted@gmail.com> wrote:
On 29/03/07, Robert Kern <robert.kern@gmail.com> wrote:
Glen W. Mabey wrote:
So, would that imply that a .copy() should be done first on any array that you want to access .data on?
Or even ascontiguousarray().
I'd like to point out that the numpy usage of the word "contiguous" is a bit misleading: while naively one would expect it to mean that the data were contiguous in memory, what it actually means is that they are contiguous and the indexing is C-ordered:
In [7]: a = arange(5)
In [8]: a.flags["CONTIGUOUS"] Out[8]: True
In [9]: a[::-1].flags["CONTIGUOUS"] Out[9]: False
In [10]: eye(2).flags["CONTIGUOUS"] Out[10]: True
In [11]: transpose(eye(2)).flags["CONTIGUOUS"] Out[11]: False
There's no help for it now, I suppose.
I think the preferred names are C_CONTIGUOUS and F_CONTIGUOUS, for instance: In [2]:eye(2).flags['C_CONTIGUOUS'] Out[2]:True In [3]:eye(2).T.flags['F_CONTIGUOUS'] Out[3]:True However, that may only be in svn at the moment. C_CONTIGUOUS is an alias for CONTIGUOUS and F_CONTIGUOUS is an alias for F. I think the new names are clearer than before. Chuck
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Charles R Harris wrote:
On 3/29/07, Anne Archibald <peridot.faceted@gmail.com> wrote:
I think the preferred names are C_CONTIGUOUS and F_CONTIGUOUS, for instance:
In [2]:eye(2).flags['C_CONTIGUOUS'] Out[2]:True
In [3]:eye(2).T.flags['F_CONTIGUOUS'] Out[3]:True
However, that may only be in svn at the moment. C_CONTIGUOUS is an alias for CONTIGUOUS and F_CONTIGUOUS is an alias for F. I think the new names are clearer than before.
FWIW, you can use attributes on flags too: In [1]: eye(2).flags.c_contiguous Out[1]: True In [2]: eye(2).T.flags.f_contiguous Out[2]: True - -- |>|\/|< /------------------------------------------------------------------\ |David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/ |cookedm@physics.mcmaster.ca -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGDEvj+kNzddXW8YwRAi9oAKDQCLoZjAPSSMscVkvVsxpiHgU4LwCgzhjD PQ4QdFd4urTaJND85u4ONbI= =ZflB -----END PGP SIGNATURE-----
participants (5)
-
Anne Archibald -
Charles R Harris -
David M. Cooke -
Glen W. Mabey -
Robert Kern