On Thu, Jun 18, 2009 at 5:42 AM, Robert Bradshaw<[email protected]> wrote: > I'm partially responsible, but this thread keeps digressing into > implementation details. As a high level view, what do people think about > > 1) Some kind of SIMD array type being added to the language. > > 2) The given proposal, which is essentially a type with syntax like > int[:,:] that would behave just like a the widely-used numpy array, > including slicing and (eventually) broadcasting, but the underlying > memory may be held by something other than an numpy object (e.g. it > could be any other buffer supporting object, or a raw pointer) and > not all numpy operations would be supported right away (or ever). >
+1 Any chance that the new Cython (nd)array play nice with Python lists, like in numpy, were you can pass a list and get it 'coerced' to numpy.ndarray? > While we're on that note, what about > > 3) Some kind of type for memory-managed lists of C types (where + is > concatenation, append is supported, memory managed, and nice > conversion to/from python lists). > I assume that by 'list of C types' you mean an plain, malloced C array, right? Then 'append' would involve a realloc() call, right? In such case, I'm +1 on this... Just looking at mpi4py's sources, I could take advantage of this in many places. > > I am in favor of all three, and obviously Dag is pushing for (1) and > (2). > I am also in favor of all three. -- Lisandro Dalcín --------------- Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC) Instituto de Desarrollo Tecnológico para la Industria Química (INTEC) Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET) PTLC - Güemes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594 _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
