Re: [Numpy-discussion] Superfluous array transpose (cf. ticket #1054)

[Pearu Peterson]

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


___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Superfluous array transpose (cf. ticket #1054)

[Sturla Molden]

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







___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Superfluous array transpose (cf. ticket #1054)

[Pearu Peterson]

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(, order='F')
  b = a + 1

instead of

  a = zeros(, order='F')
  b = a[:]
  b += 1

to keep the storage properties in operations.

Regards,
Pearu



___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Superfluous array transpose (cf. ticket #1054)

[Pauli Virtanen]

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

___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion