[Numpy-discussion] Fwd: Advanced selection, duplicate indices, and augmented assignment

Charles R Harris charlesr.harris at gmail.com
Wed Jan 10 22:36:58 EST 2007

On 1/10/07, Timothy Hochberg <tim.hochberg at ieee.org> wrote:
> On 1/8/07, Timothy Hochberg <tim.hochberg at ieee.org > wrote:
> >
> >
> >
> > On 1/7/07, Sean R. Lynch < seanl at literati.org> wrote:
> > >
> > > Travis Oliphant wrote:
> > >
> > > > I don't think we could make it work as he expects (and not radically
> > > > change NumPy itself so that other operations are very different)
> > > because
> > > > of the limitations of Python.
> > > >
> > > > The point was that it is too complicated to do any differently (and
> > > is
> > > > probably impossible).
> > >
> > > Ok, thanks for the explanation.
> > >
> > > In that case, is there a way to do what I want (accumulate values per
> > > index) without looping in Python? The histogram functions would only
> > > count the number of uses of a given index AFAICT. I want to sum all of
> > > the normals for a given index.
> >
> >
> > Sean,
> >
> > I'm pretty sure that at one point I had a way to do exactly what you are
> > doing, however it's been a while and I don't know where that code wandered
> > off to. I will think about it now that I'm done doing silly stuff and see if
> > I can recall what the trick was.
> >
> > [Just don't want you to feel abandoned...]
> >
> OK, *now* you can feel abandoned. I've thought about this for a couple of
> days and  I can't see an efficient way to do it with the current set of
> primitives. I think that when I did normal blending before I might have been
> working on rectangular grid so every vertex had three neighbors or something
> like that.
> You're the second or third person to recently come up with a useful
> application for using inplace ops with repeated indices only to be stymied
> by that fact that they don't actually work that way. I've been wondering if
> we should try to come up with a way to support this usage. Although it might
> be feasible to make += work, the implementation is horrible, and there are
> all sorts of inefficiencies built into that method of doing it.
> The natural approach would seem to be to hang another method off the
> ufuncs. That way you get support for all of the various operations. I was
> thinking something like:
> unfunc.inplace (dest, indices, source)

Yeah, something like that. A general indirect addressing primitive of some
sort would be useful for these situations. The indices are sort of pointers
into the destination, the problem is how to bind this to operators. It
should almost be some sort lvalue analogous to **p = whatever, or in this
case dest[index[j]] {assignment} src[j]. So maybe indirect(dest, indices,
source, op). Then there is all the madness of fancy indexing (which I think
I could have done without). Because the current applications are limited and
could be met with the simplest 1D version, it would probably be best to
start with the most basic functionality and then extend it if the need
arose. Or maybe even some simple c extension that did the whole basic +=
thing for one dimension.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20070110/facc1bf0/attachment.html>

More information about the NumPy-Discussion mailing list