FW: [Numpy-discussion] Re-implementation of Python Numerical arrays (Numeric) available for download
greenfield at home.com
Sat Nov 17 14:58:02 CST 2001
> What I've seen looks great. You've all done some good work here.
Thanks, you were origin of some of the ideas used.
> Of course, I do have some feedback. I haven't looked at
> everything, these
> points have just caught my eye.
> Complex Types:
> 1) I don't like the idea of complex types being a separate subclass of
> ndarray. This makes them "different." Unless this "difference" can be
> completely hidden (which I doubt), I would prefer complex types
> to be on the
> same level as other numeric types.
I think that we also don't like that, and after doing the original,
somewhat incomplete, implementation using the subclassed approach,
I began to feel that implementing it in C (albeit using a different
approach for the code generation) was probably easier and more
elegant than what was done here. So you are very likely to see
it integrated as a regular numeric type, with a more C-based
> 2) Also, in your C-API, you have a different pointer to the
> imaginary data.
> I much prefer the way it is done currently to have complex numbers
> represented as an 8-byte, or 16-byte chunk of contiguous memory.
Any reason not to allow both? (The pointer to the real can be interpreted
as either a pointer to 8-byte or 16-byte quantities). It is true
that figuring out the imaginary pointer from the real is trivial
so I suppose it really isn't necessary.
> Index Arrays:
> 1) For what it's worth, my initial reaction to your indexing scheme is
> negative. I would prefer that if
> a = [[1,2,3,4],
> a[[1,3],[0,3]] returns the sub-matrix:
> [[ 4, 6],
> [ 12, 14]
> i.e. the cross-product of [1,3] x [0,3] This is the way MATLAB
> works. I'm
> not sure what IDL does.
I'm afraid I don't understand the example. Could you elaborate
a bit more how this is supposed to work? (Or is it possible
there is an error? I would understand it if the result were
[[5, 8],[13,16]] corresponding to the index pairs
> If I understand your scheme, right now, then I would have to
> append an extra
> dimension to my indexing arrays to get this behavior, right?
> 2) I would like to be able to index the array in a flattenned
> sense as well
> (is that possible?) in other words, it would be nice if
> a[flat(9,10,11)] or
> something got me the elements 9,10,11 in a one-dimensional
> interpretation of
> the array.
> 3) Why can't you combine slice notation and indexing? Just interpret the
> slice as index array that would be created from using tha range
> operator on
> the same start, stop, and step objects. Is this the plan?
I think that allowing slicing could be possible. But things were
getting pretty complex as they were, and we wanted to see if
there was agreement on how it was being done so far. It could
be extended to handle slices, if there was a well defined
interpretation. (I think there may be at least two possible
interpretations considered). As for the above, sure, but of
course the slice would have to be shape consistent with
the other index arrays (under the current scheme).
> That's all for now. I don't mean to be critical, I'm really
> impressed with
> what works so far. These are just some concerns I have right now.
> -Travis Oliphant
Thanks Travis, we're looking for constructive feedback, positive
More information about the Numpy-discussion