Superfluous array transpose (cf. ticket #1054)
Regarding ticket #1054. What is the reason for this strange behaviour?
a = np.zeros((10,10),order='F') a.flags C_CONTIGUOUS : False F_CONTIGUOUS : True OWNDATA : True WRITEABLE : True ALIGNED : True UPDATEIFCOPY : False (a+1).flags C_CONTIGUOUS : True F_CONTIGUOUS : False OWNDATA : True WRITEABLE : True ALIGNED : True UPDATEIFCOPY : False
Sturla Molden
Sun, 15 Mar 2009 19:57:10 +0100, Sturla Molden wrote:
Regarding ticket #1054. What is the reason for this strange behaviour?
a = np.zeros((10,10),order='F') a.flags C_CONTIGUOUS : False F_CONTIGUOUS : True OWNDATA : True WRITEABLE : True ALIGNED : True UPDATEIFCOPY : False (a+1).flags C_CONTIGUOUS : True F_CONTIGUOUS : False OWNDATA : True WRITEABLE : True ALIGNED : True UPDATEIFCOPY : False
New numpy arrays are by default in C-order, I believe. -- Pauli Virtanen
On Sun, March 15, 2009 8:57 pm, Sturla Molden wrote:
Regarding ticket #1054. What is the reason for this strange behaviour?
a = np.zeros((10,10),order='F') a.flags C_CONTIGUOUS : False F_CONTIGUOUS : True OWNDATA : True WRITEABLE : True ALIGNED : True UPDATEIFCOPY : False (a+1).flags C_CONTIGUOUS : True F_CONTIGUOUS : False OWNDATA : True WRITEABLE : True ALIGNED : True UPDATEIFCOPY : False
I wonder if this behavior could be considered as a bug because it does not seem to have any advantages but only hides the storage order change and that may introduce inefficiencies. If a operation produces new array then the new array should have the storage properties of the lhs operand. That would allow writing code a = zeros(<shape>, order='F') b = a + 1 instead of a = zeros(<shape>, order='F') b = a[:] b += 1 to keep the storage properties in operations. Regards, Pearu
On 3/16/2009 9:27 AM, Pearu Peterson wrote:
If a operation produces new array then the new array should have the storage properties of the lhs operand.
That would not be enough, as 1+a would behave differently from a+1. The former would change storage order and the latter would not. Broadcasting arrays adds futher to the complexity of the problem. It seems necessary to something like this to avoid the trap when using f2py: def some_fortran_function(x): if x.flags['C_CONTIGUOUS']: shape = x.shape[::-1] _x = x.reshape(shape, order='F') _y = _f2py_wrapper(_x) shape = _y.shape[::-1] return y.reshape(shape, order='C') else: return _f2py_wrapper(x) And then preferably never use Fortran ordered arrays directly. Sturla Molden
On Mon, March 16, 2009 4:05 pm, Sturla Molden wrote:
On 3/16/2009 9:27 AM, Pearu Peterson wrote:
If a operation produces new array then the new array should have the storage properties of the lhs operand.
That would not be enough, as 1+a would behave differently from a+1. The former would change storage order and the latter would not.
Actually, 1+a would be handled by __radd__ method and hence the storage order would be defined by the rhs (lhs of the __radd__ method).
Broadcasting arrays adds futher to the complexity of the problem.
I guess, similar rules should be applied to storage order then. Pearu
participants (3)
-
Pauli Virtanen -
Pearu Peterson -
Sturla Molden