[Matrix-SIG] [PSA MEMBERS] Numeric Python Set function

[Janko Hauser]

David Ascher writes:
 > I don't remember the exact specifics of Zane's function.  Something like
 > it needs to be incorporated not only in NumPy, but in the *indexing*
 > (setitem) mechanism.  I've done some preliminary work on this, and there
 > are a couple of non-trivial issues -- specifically, it'd be nice to be
 > able to do: 
 > 
 >    a[a>100] = 100
 > 
 > as well as a more general form,
 > 
 >    a[b] = c
 > 
 > where b contains some description of the indices of a which need to get
 > their values from c.
 > 
 > Note that a simplistic implementation will act strangely for at least one
 > of these under some conditions (since the first index (a>100) corresponds
 > (or will, someday) to an array of 1's and 0's.  Replace the RHS of the
 > first example with an array, and you have an ambiguity).  There are ways
 > around this, which, I believe, localize the complexity to the array
 > object.  I've been playing with one way to deal with this, which is
 > basically to usurp the tp_call/__call__ slots, just because they were
 > there (and because Don Beaudry has, as we know, a twisted mind). Upon
 > further reflection, I think that coming up with a specialized new slot
 > (for arrays and arraylike instances) is the right thing to do.

Am I right, that these forms of indexing are only possible with a
ravel(a) array? Isn't it possible to expand the slice type, so one can 
define indexes along each dimension? (give me any row, where soem
value is bigger than 10)

If the slice type defines something like this other sequence objects
can start to use this way of indexing with the definition of an
additional method (is it getitem or getslice?).

 > under a fair amount of other stuff.  It's nice to see that there is a
 > constituency out there, though. =)
 > 
 > --david

 > 
 > PS: Folks should also definitely remember Chris Chase's effort, which is a
 >     Python-only solution (hence lacked the speed I often need), but
 >     defined a fuller set of features (ellipses, NewAxis, etc.).  It's
 >     available on the findmail archives.  I don't remember the exact name
 >     of the file, but I can resurrect it if it's hard to find.  I vaguely
 >     remember some discussion where Zane was saying that he didn't
 >     implement all of these (which I think would be nice to have, at least
 >     in the final version).
 >   

Also Timothy Hochberg has something along this line implemented in
Python in his FancyArray - UserArray class. It's at his Starship site.

__Janko