On Tue, 17 Sep 2002, Travis Oliphant wrote:
len(d) == Exception == d.shape[0]
# Currently the last is wrong?
Agreed, but this is because d is an integer and out of Numerics control. This is a case for returning 0d arrays rather than Python scalars.
That is one problem. It can be removed by using shape(d). More fundamentally, though, len(d) == shape(d)[0] == ()[0] => IndexError. I think Konrad made this point a few days back.
size(d) == 1 == product(d.shape)
# Currently the last is wrong
I disagree that this is wrong. This works as described for me.
Right. Change d.shape to shape(d) here (and in several other places).
Why is this? I thought you argued the other way for len(scalar). Of course, one solution is that we could overwrite the len() function and allow it to work for scalars.
Raising exception is the correct behavior, not a problem to be solved.
Conclusion 5: rank-0 int arrays should be allowed to act as indices. See property 5.
Can't do this for lists and other builtin sequences.
If numarray defines a consistent set of behaviors for integer types that is intuitively understandable, it might not be difficult to persuade core Python to check against an abstract integer type.
- Is there substantial difference in overhead between rank-0 arrays and scalars?
Yes.
That would be one major problem. However, after giving this some more thoughts, I'm starting to doubt the analogy I made. The problem is that in the end there is still a need to index an array and obtain a good old immutable scalar. So - What notation should be used for this purpose? We can use c[0] to get immutable scalars and c[0,] for rank-0 arrays / mutable scalars. But what about other ranks? Python does not allow distinctions based on a[1,1,1] versus a[(1,1,1)] or d[] versus d[()]. - This weakens the argument that rank-0 arrays are scalars, since that argument is essentially based on sum(c) and c[0] being of the same type. Huaiyu