Front page | perl.perl6.internals |
Postings from June 2002
Re: matrix design
Thread Previous
|
Thread Next
From:
Ashley Winters
Date:
June 19, 2002 08:39
Subject:
Re: matrix design
Message ID:
200206190137.03684.qaqortog@nwlink.com
On Wednesday 19 June 2002 08:11 am, Sean O'Rourke wrote:
> On Wed, 19 Jun 2002, Dan Sugalski wrote:
> > At 4:37 PM +0200 6/19/02, =?latin1?Q?Josef_H=F6=F6k?= wrote:
> > >I do sense a question arrising here..
> > >If we should include matrices in parrot what should we and not include
> > > in parrot?
> >
> > Start simple and work up from there. Once you have a base PMC type
> > that handles storing multidimensional data, you can add things to it.
>
> But not too simple, at least on the interface end of things. Even with a
> lot of time and expertise, we won't be able to create a matrix
> implementation that satisfies everyone's needs (see BLAS, POOMA, MTL,
> ....). It seems like we should provide a good general set of matrix
> opcodes, plus a reference implementation that is good enough for
> less-serious numerical folks. The truly hard-core can then map their
> favorite matrix library onto these opcodes with minimal overhead.
> Unfortunately, to be "good enough", it will have to be possible to avoid
> creating temporaries in arbitrary matrix expressions. Doing "A = BC + DE"
> as
>
> mul X, B, C
> mul Y, D, E
> add A, X, Y
Considering how much of Perl6 is based on lazy evaluation, I'm surprised
everyone's worried about immediate operations on matrices. PDL or someone
will implement a queue of the calculations in the destination PMC till it's
read, and then optimize the heck out of it. All Parrot would need to do is
provide an example copy-on-write matrix data type.
I don't think you need to worry about optimizing complex operations too much,
the PDL people have come up with miracles before... they just need the tools.
Ashley Winters
Thread Previous
|
Thread Next