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

Andrew P. Mullhaupt amullhau@nospam.ix.netcom.com
Mon, 08 Jun 1998 19:20:15 -0400

David Ascher wrote:
> On Fri, 5 Jun 1998, Paul F. Dubois wrote:
> > I think array_set does sound like an important function.
> 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.

Correct. And without any real doubt at the end of several decades of
numerical computing with interpreted array languages.

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

No problem.
> 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.

> The nice thing about this approach is that arrays of different species can
> define different ways to do the indexing (thus arrays which correspond to
> logical operations on arrays would "know" that they are masks, whereas
> arrays which are returned by other functions would know that they are
> indices, etc). It also means that one could have a version of NumPy which
> just provides the hooks for this, and various folk can propose specific
> mechanisms (see the old debate on S+ vs.  APL vs. etc. indexing).

Yes, but either one is better than what NumPy currently provides. S
style indexing is better, but in full generality relies on using a nice
representation for unavailable elements.

Aaron Watters knows about seventeen flavors of how to handle
unavailables, but one good way for array computation is the S way.

But if people are going to have a fight over NAs to hang up indexing,
then let's at least get APL style going.
> I'd hoped to post about this when I had a proof-of-concept finished.

Tell me about it.

Andrew Mullhaupt