Re: [Numpy-discussion] order flag again
On 01:46 PM Tim Hochberg wrote:
As I've mentioned before, I'd like to sweep all of the operations that may return a view or a copy into a few asXXXarray functions so that these potentially problematic operations are localized and easily identifiable.
+1 on the idea that: asXXXarray: functions which take their input and return always an array, but trying to avoid copies if at all possible. This means that code calling such functions should treat their returned values strictly as /inputs/, never modifying them in place. These functions are provided by numpy strictly for performance reasons. Or something like that. I like being able to tell to users that this kind of problem is solved by a unified familiy of functions in the API, with a clear naming convention. There is a need for them, but they are also a bit dangerous, so they should be clearly labeled. Painting them all in the same bright red helps indicate their 'sharp blade' nature. Cheers, f
On 3/27/06, Fernando Perez
On 01:46 PM Tim Hochberg wrote:
As I've mentioned before, I'd like to sweep all of the operations that may return a view or a copy into a few asXXXarray functions so that these potentially problematic operations are localized and easily identifiable.
+1 on the idea that:
asXXXarray: functions which take their input and return always an array, but trying to avoid copies if at all possible. This means that code calling such functions should treat their returned values strictly as /inputs/, never modifying them in place. These functions are provided by numpy strictly for performance reasons.
How about Tim's example: b = asarray(a).reshape(newshape) Or something like that. I think the problem is mixing python list types with arrays. It is convenient but we get into trouble. What purpose does ascontiguous serve? I like being able to tell to users that this kind of
problem is solved by a unified familiy of functions in the API, with a clear naming convention. There is a need for them, but they are also a bit dangerous, so they should be clearly labeled. Painting them all in the same bright red helps indicate their 'sharp blade' nature.
Cheers,
f
Chuck
Charles R Harris wrote:
What purpose does ascontiguous serve?
One I can think of: making sure that C code of the type double foo(double *array,long num_elements) { ... } can be called in C as foo((double *)numpy_arr->data,numpy_arr->dimensions[0]); (the dims name in C may be different, I'm not looking at code right now) and be OK with walking the given memory region as a contiguous chunk of doubles, num_elements of them. As long as foo() doesn't modify its input, this works fine and it's nice to have such guarantees: it makes writing extension code a lot easier. Cheers, f
On 3/27/06, Fernando Perez
Charles R Harris wrote:
What purpose does ascontiguous serve?
One I can think of: making sure that C code of the type
double foo(double *array,long num_elements) { ... }
can be called in C as
foo((double *)numpy_arr->data,numpy_arr->dimensions[0]);
(the dims name in C may be different, I'm not looking at code right now)
and be OK with walking the given memory region as a contiguous chunk of doubles, num_elements of them.
As long as foo() doesn't modify its input, this works fine and it's nice to have such guarantees: it makes writing extension code a lot easier.
OK, it's an interface. Since getting stuff back from C will require a copy if the original is not contiquous, a test involving a.iscontiguous will be needed and ascontiguous can be dispensed with. Isn't there a C version of this anyway? ISTR that numarray had one. Chuck
Charles R Harris wrote:
On 3/27/06, *Fernando Perez*
mailto:Fernando.Perez@colorado.edu> wrote: Charles R Harris wrote:
> What purpose does ascontiguous serve?
One I can think of: making sure that C code of the type
double foo(double *array,long num_elements) { ... }
can be called in C as
foo((double *)numpy_arr->data,numpy_arr->dimensions[0]);
(the dims name in C may be different, I'm not looking at code right now)
and be OK with walking the given memory region as a contiguous chunk of doubles, num_elements of them.
As long as foo() doesn't modify its input, this works fine and it's nice to have such guarantees: it makes writing extension code a lot easier.
OK, it's an interface. Since getting stuff back from C will require a copy if the original is not contiquous, a test involving a.iscontiguous will be needed and ascontiguous can be dispensed with. Isn't there a C version of this anyway? ISTR that numarray had one.
It think you are talking about the UPDATEIFCOPY requirements flag on the PyArray_FromAny C-API. Most aren't using this yet (and it's not directly exposed to Python). But it's how you would get a copy of the array with the correct requirements, operate on it and then once you delete your reference have the information go back into the original array (this is true whether or not the array is contiguous). The original array is also set to be read-only during the time that the copy is available so that you can't make changes to it (that are going to be lost). Perhaps what we need to do is make this scheme available to the Python user as well. -Travis
participants (3)
-
Charles R Harris
-
Fernando Perez
-
Travis Oliphant