On Mon, Aug 8, 2011 at 11:55 PM, Joel Berger <[email protected]> wrote:
> On Fri, Aug 5, 2011 at 12:33 PM, Chris Marshall <[email protected]>
> wrote:
>>
>> On Fri, Aug 5, 2011 at 12:12 PM, Joel Berger <[email protected]> wrote:
>> > I see that you are working on NiceSlice2, but I keep wondering if there
>> > isn't some way to do something like it (probably not drop-in replacement)
>> > using Devel::Declare.
>>
>> Interesting. I'm not sure it would work so well to upgrade
>> PDL::NiceSlice but it could work for adding a FORALL construct
>> to pdl.
>
> More as a reason to try I have implemented a PDL::DeclareSlice
> available on my github at https://github.com/jberger/PDL-DeclareSlice
> of which all the important bits are in the module (should you not want
> to go through the rigmarole of Dist::Zilla). As I suspected it isn't a
> drop-in replacement, you need a keyword to initiate the slice. I'd be
> interested if there are comments and would this be something worth
> pursuing further. Its benefit is that it doen't use the source filter,
> of course I'm sure it has edge cases just like a source filter would
> have so perhaps thats not too much of an improvement.
One of the motivations/advantages of NiceSlice syntax is that
it allows array-type access to pdls. The keyword approach
loses that.
> One more question, is there any real magic in the nslice method? For
> now all my sugar does is convert to a slice call (i.e., `sl $pdl(1:4)`
> to `$pdl->slice("1:4")`).
>From the PDL::NiceSlice documentation: "The C<nslice> method is an
extended version of L<mslice|PDL::Core/mslice> that knows how to deal
with index piddles (and therefore combines slicing and dicing). Full
documentation of C<nslice> will be in the next PDL release.
I don't think the promised "full documentation" has been written yet.
> What kind of FORALL did you have in mind? Perhaps I can take a look.
The idea was a FORALL construct a la F95 or HPF that would
allow us to write a computational kernel in a way that could be
better optimized for memory/cache performance. See the discussion
around this post:
http://mailman.jach.hawaii.edu/pipermail/perldl/2010-July/003669.html
If you are not familiar with FORALL, here are some examples of
the fortran version:
FORALL (j=1:m, k=1:n) x(k,j) = y(j,k)
FORALL (k=1:n) x(k,1:m) = y(1:m,k)
Transpose operation.
FORALL (i=1:n, j=1:n) x(i,j) = 1.0 / REAL(i+j-1)
Easy expression of coordinate functions without
a mess of temporaries. A performance optimization
opportunity.
FORALL (i=1:n, j=1:n, y(i,j).NE.0.0) x(i,j) = 1.0 / y(i,j)
Easy masking for computations. Less temps.
FORALL (i=1:n) x(indx(i)) = x(i)
Permutation of elements, does not handle
collisions.
FORALL (i=2:4) x(i) = x(i-1) + x(i) + x(i+1)
This is the same as the following:
x(2:4) = x(1:3) + x(2:4) + x(3:5)
but is not a mess of indexes and strides.
FORALL (i=1:n) a(i,i) = x(i)
Much easier to express the diagonal this way
FORALL (i=1:4) a(i,ix(i)) = x(i)
Combines coordinate indexing and indirect
index lookup. Can handle mulidimensional
case.
FORALL (k=1:9) x(k) = SUM(x(1:10:k))
Is this allowed for the PDL syntax?
>> > Also, and while I have tried I have failed miserably, I have been wanting
>> > to
>> > figure out how to make a useful PDL type for Moose, and most importantly
>> > compatible with MooseX::Storage. That way I can make my physics simulations
>> > within Moose and have attributes which are piddles and cache results for
>> > future use.
>>
>> I'm only familiar with Moose enough to implement the pdl2
>> shell but maybe you could do this by implementing a wrapper
>> class for pdl using the has-a approch as in PDL::Objects.
>> That might provide enough perl "glue" to get the job done...
>>
>
> Thanks for that hint, I'm taking a look at it now, it does seem more
> promising.
Let us know how this turns out.
Cheers,
Chris
_______________________________________________
Perldl mailing list
[email protected]
http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
