[Numpy-discussion] array, asarray as contiguous and friends

Tim Hochberg tim.hochberg at cox.net
Fri Mar 24 08:22:17 CST 2006

Colin J. Williams wrote:

> Tim Hochberg wrote:
>> Colin J. Williams wrote:
>>> Tim Hochberg wrote:
>>>> I was just looking at the interface for array and asarray to see 
>>>> what other stuff should go in the interface of the hypothetical 
>>>> ascontiguous.  There's 'dtype', which I knew about, and 'fortran', 
>>>> which I didn't, but which makes sense. However, there's also 
>>>> 'ndmin'. First off, it's not described in docstring for asarray, 
>>>> but I was able to find it in the docstring for array without a 
>>>> problem. Second, is it really necessary? It seems to be useful in 
>>>> an awfully narrow set of circumstances, particularly since when you 
>>>> are padding axes not everyone wants to pad to the left.
>>>> It would seem to be more useful to ditch the ndmin and have some 
>>>> sort of paddims function that was more full featured (padding to 
>>>> either the left or the right at a minimum). I'm not entirely sure 
>>>> what the best interface to such a beast would look like, but a 
>>>> simple tactic would be to just provide leftpaddims and rightpaddims.
>>>> If it's not allready clear by now (;), I prefer several narrow 
>>>> interfaces to one broad one.
>>>> -tim
>>> What does ascontiguous do that copy doesn't?  
>> What it doesn't do is always copy the argument. Just like asarray, it 
>> returns it unchanged if it's contiguous.
> Fair enough.  I guess that, for some array a, "b= ascontiguous(a)"  
> saves a few keystrokes as compared
> with "b= a if a.flags.contiguous else a.copy()".  The intent of the 
> latter is clearer and probably burns fewer cycles.

First, the second expression is not equivalent to ascontiguous. Second, 
I disagree strongly that it's clearer. Third, if cycles are actually a 
concern, ascontiguous if implemented in C would certainly be faster. 
Fourth, this can't be written in any released version of Python.

Let me go into a little more detail on the first and second points. The 
common use case for asarray and ascontiguous is to adapt objects that 
you don't know much about into arrays. A typical pattern is:

def func(a, b, c):
    a = asarray(a)
    b = ascontiguous(b)
    c = asarray(c)
    # Code that requires arrays for a,c and a contigous array for b.

For this reason, as contiguous needs to take any object and attempt to 
turn it into a contiguous array if it isn't one already. So "b = 
ascontiguous(a)" is really equivalent to "b = asarray(a); b = b if 
b.flags.contiguous else b.copy()".  Even if we could assume all the 
inputs were arrays, or we separately use as array first, the pattern you 
propose is error prone since it violates DRY. It would be all to easy to 
write "b= a if c.flags.contiguous else a.copy()" or some such. In order 
to verify that the expressions are correct, or in order to tell what 
they actually do you have to actually parse through the expression. 
"ascontiguous", on the other hand, is pretty much bomb proof once you 
know what it does.

> numarray has an iscontiguous method, which is a bit simpler than 
> concerning the Python user with flags.
>>> In numarray, transpose created a discontiguous array.  copy() made 
>>> the array contiguous.  Is there sufficient benefit to justify 
>>> another method?
>> I was proposing a function, not a method. The array object has plenty 
>> of methods already.
> Since the function would only operate on ArrayType instances, would it 
> not be better as a method?

Your premise is wrong. It would operate on any object, so it has to be a 
function. It could also be a method, but that would be superfluous.



More information about the Numpy-discussion mailing list