[Matrix-SIG] Numeric Nits

[Tim Hochberg]

>The original design decision was that rank-0 arrays should never be
>returned from any common operation because of their somewhat weird
>behaviour. In principle rank-0 arrays *are* scalars, and in fact
>rank-0 arrays practically behave like Python scalars, but many
>routines that expect scalars will not accept rank-0 arrays. It would
>be very confusing to have two kinds of data that are almost the same.


I'll concede that virtually all the operations should go ahead and return
scalars. However, the original poster referred to '-array([5])' returning a
scalar. I haven't been able to think of any situations where people are
going to be using negative on a rank-0 array without expecting the result to
also be a rank-0 array. The chance of the rank-0 array's produced this way
getting loose and hurting people seems slim.

I suppose consistency would demand that '~' also get changed.

I'm not sure whether this would be a good idea or not, but I figured it's
worth discussing in light of the recent flurry of posts regarding upcasting.

>Another problem is that there is no clean way to extract a scalar from
>a rank-0 array. Indexing requires a number of indices which is at most
>equal to the rank, but you can't index with zero indices! In practice,
>rank-0 arrays can be indexed with one index that has to be zero, but
>that's a kludge rather than good design.


Actually, I've disallowed this in JPython because it is,as you say, a
kludge. There are however two ways of getting at the value in a rank-0
array.

a[()]
a[...]

I prefer the first (not just because it's shorter...).



[SNIP]

>That would create all the well-known problems of a global interpreter
>status. What if you ask for single-precision and then call a subroutine
>that expects double? What if you call a subroutine that changes the
>precision? And what about thread-safety?


It's guilty of all these things. It was suggested as a way to make using the
interpreter in interactive mode with floats less painful. I suppose it could
cause lots of trouble if misused though.

This isn't a very good solution in many ways, but it's the best one I've
seen so far. Using floats is enough of a pain that it would probably kill
you in interactive mode, so I think the lack of support for floats is a
legitimate complaint. I would love to see a better solution than this one
though.

>> The big advantage of this approach is it's gauranteed to not break any
code.
>
>Only if it's not used! ;-)


That's true of almost anything I suppose.

-tim