On 03/22/12 at 11:47P, Andreas Kloeckner wrote:
Sure, if you'd like to take a crack at this, I'd be more than
help. Here's the story:
The code is in pyopencl/compyte/scan.py
Start from a git checkout.
I'm wondering whether it would be better to use the existing code, or
whether to steal scan_by_key and possibly reduce_by_key from thrust,
which seems so be the way scan.py come to be :)
It should make no difference whatsoever for the features you mention.
- Allow evaluation of a map before the scan starts, without ever
explicitly storing the map result. Such a map *could* (but wouldn't be
required to) involve widening each entry of the array to a struct that
contains the entry and a segment flag. The map would be fed in as a C
expression (i.e. as a string) and would be allowed to use all the
arguments given to the kernel (same idea as ElementwiseKernel), and it
would have its desired index available in the formal variable 'i'.
So you could do elementwise operation before scan but without invoking
another kernel. That makes sense.
- A separate (Boolean-valued) expression (defaulting to None) that
marks segment boundaries, based on array indices and intermediate
Also there probably should be some way to specify the segment boundaries
explicitly and not through a function, but that might get expensive for
large arrays. Something in my head makes me say "sparse arrays" but I'm
not sure how much (if any) support is in pyopencl or opencl.
Also, I'm I blind or is there not tranpose in pyopencl?