On 1/10/07, Timothy Hochberg <[EMAIL PROTECTED]> wrote:
On 1/8/07, Timothy Hochberg <[EMAIL PROTECTED] > wrote:
>
>
>
> On 1/7/07, Sean R. Lynch < [EMAIL PROTECTED]> 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.
Chuck
_______________________________________________
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
