[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.
Yup.
> 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.
Later,
Andrew Mullhaupt