[Numpy-discussion] array, asarray as contiguous and friends
Colin J. Williams
cjw at sympatico.ca
Fri Mar 24 07:06:04 CST 2006
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]>>> c= b.transpose()
>> 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.
> # 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
> Embrace simplicity: you have nothing to lose but your clutter;)
If [***] above were adopted, it would still be helpful to adopt
numarray's iscontiguous method, or better, use a property.
More information about the Numpy-discussion