-----Original Message-----

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 implementation.

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], [5,6,7,8], [9,10,11,12], [13,14,15,16]]

then

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 [[(1,0),(1,3)],[(3,0),(3,3)]])

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.

Why not: ravel(a)[[9,10,11]] ?

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 or negative. Perry