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

[Colin J. Williams]

Tim Hochberg wrote:

> Sasha wrote:
>
>> On 3/23/06, Travis Oliphant <oliphant at ee.byu.edu> wrote:
>>  
>>
>>> At any rate, if the fortran flag is there, we need to specify the
>>> contiguous case as well.   So, either propose a better interface (we
>>> could change it still --- the fortran flag doesn't have that much
>>> history) to handle the situation or accept what I do ;-)
>>>   
>>
>>
Contiguity is separable from fortran:
[Dbg]>>> b= _n.array([[1, 2, 3], [4, 5, 6]])
[Dbg]>>> b.flags.contiguous
True
[Dbg]>>> c= b.transpose()
[Dbg]>>> c
array([[1, 4],
       [2, 5],
       [3, 6]])
[Dbg]>>> c.flags.contiguous
False
[Dbg]>>>

>> Let me try. I propose to eliminate the fortran flag in favor of a more
>> general "strides" argument.  This argument can be either a sequence of
>> integers that becomes the strides, or a callable object that takes
>> shape and dtype arguments and return a sequence that becomes the
>> strides.  For fortran and c order functions that generate appropriate
>> stride sequences should be predefined to enable array(...,
>> strides=fortran, ...) and array(..., strides=contiguous).
>>
>
> I like the idea of being able to create an array with custom strides. 
> The applications aren't entirely clear yet, but it does seem like it 
> could have some interesting and useful consequences. That said, I 
> don't think this belongs in 'array'. Historically, array has been used 
> for all sorts of array creation activities, which is why it always 
> seems to have a wide, somewhat incoherent interface. However, most 
> uses of array() boil down to one thing: creating a *new* array from a 
> python object. My preference would be to focus on that functionality 
> for array() and spin of it's other historical uses and new uses, like 
> this custom strided array stuff, into separate factory functions. For 
> example (and just for example, I make no great claims for either this 
> name or interface):
>    a = array_from_data(a_buffer_object, dtype, dims, strides)      [***]
>
> One thing that you do make clear is that contiguous and fortran should 
> really two values of the same flag. 

Please see the transpose example above.

> If you combine this with one other simplification: array() always 
> copies, we end up with a nice thin interface:
>    # Create a new array in 'order' order. Defaults to "C" order.
>    array(object, dtype=None, order="C"|"FORTRAN")

I feel that [***] above is much cleaner than this.  I suggest that 
string constants be deprecated.

> and
>    # Returns an array. If object is an array and order is satisfied, 
> return object otherwise a new array.
>   # If order is set the returned array will be contiguous and have 
> that ordering
>    asarray(object, dtype=None, order=None|"C"|"FORTRAN")
>    # Just the same, but allow subtypes.
>    asanyarray(object, dtype=None, order=None|"C"|"FORTRAN")
>
> You could build asarray, asanyarray, etc on top of the proposed array 
> without problems by using type(object)==ndarray and isinstance(type, 
> ndarray) respectively. Stuff like convenience functions for minnd 
> would also be easy to build on top of there. This looks great to me 
> (pre-coffee).
>
> Embrace simplicity: you have nothing to lose but your clutter;)
>
> Regards,
>
> -tim
>
If [***] above were adopted, it would still be helpful to adopt 
numarray's iscontiguous method, or better, use a property.

colin W.