[MATRIX-SIG] A proposal (LONG) - "reverse of take" revisited

[Andrew P. Mullhaupt]

At 08:34 PM 7/11/97 -0400, Chase, Chris wrote:
>
>  I was asking what should the behavior of arrays as indexes be with
>respect to array bounds and I was illustrating two possible behaviors
>now seen in NumPy.  Reasonable possible behaviors for arrays used as
>indexes when the indexes are outside the array bounds:
>
>1) project the indexes onto the bounds.  This takes the intersection of
>the bounds and the index dropping individual indexes outside the bounds.
>This is the type of behavior currently exhibited by slices.  The problem
>with clipping is that you get back fewer elements than expected.

This is not normally considered a reasonable behavior, however it isn't
a disaster.

You get all sorts of weird ideas for this kind of stuff in different
array languages. APL gives an error for any access outside the shape
of an array. 

Now S-plus is _pretty_ weird for this:

> A <- array(1:6, dim=c(3,2))
> A
     [,1] [,2]
[1,]    1    4
[2,]    2    5
[3,]    3    6
> A[3, 2]
6
> A[6]
6
> A[7]
NA
> A[1,4]
Error in A[1, 4]: Array subscript  (4) out of bounds. should be at most 2
Dumped
> A[7] <- 7
> A
     [,1] [,2]
[1,]    1    4
[2,]    2    5
[3,]    3    6
> A[7]
7
> A[1,4] <- 7
Error in A[1, 4] <- 7: Array subscript  (4) out of bounds. should be at most 2
Dumped

Cool, right? I don't want to get into a discussion of why this happens, just
want to point out that it comes from the way S-plus uses object orientation
- it has to do with arrays acting like a subclass of vectors but having
different methods for out-of-bounds accesses.

But wait! Matlab is the _exact converse_!. You can't interrogate an element
outside the shape of the array, but if you _assign_ one then the array
expands. But not if it's a vector.

Moral of the story: This is an issue where you can adopt really screwy
ideas and people might still buy and use your product. So I suppose
silently truncating indices might make sense to somebody, although
at the moment it seems somewhat risky and eccentric.

This is not to say that it doesn't matter, though. People who make mistakes
and over-access an array probably will appreciate errors being raised.
People who want to work with sparse matrices will absolutely hate those
errors.

>2) project the indexes by clipping.  This clips indexes outside the
>bounds to the bounds.  For example, an index of [20] on a size 3 array
>uses [2] as the index.  This is the way IDL array indexes behave (which
>is incongruous with the errors that out-of-bounds scalar indices
>generate in IDL).  For some applications this can be convenient while in
>other situations you would prefer an error.

Just so. Another array language, another different way of handling out of
bounds indices. Can anyone think of two different languages which handle
this the same way?

>3) generate an error.  This is the behavior of take() when the index is
>out of bounds.

Good old APL style. This has the virtue that even if it isn't making you
happy, it's easy to understand and expect. You could do worse.

Later,
Andrew Mullhaupt

_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________