Tuomas Lukka wrote:
> > Do we really need PDL objects in perl 6? How about we investigate building
> > compact arrays into the language? We're already talking about how we can add
> > typing to the language--I would have thought that if these semantics make it
> > in, we could look to optimise how numeric types are stored.
> >
> > I think we should look to remove the distinction between 'stuff that works
> > in PDL' and 'stuff that works in perl'. To do this I guess we need an RFC
> > proposing compact array storage for numeric data. Most of the rest of PDL
> > core is already proposed in one form or another. Stuff like SLATEC support
> > still belongs in external modules, of course.
>
> Again, sorry that I can only offer support from the sidelines and not take
> up the task of writing an RFC. One VERY important thing to remember about
> the compact data types that PDL deals with is that of smart pointers: e.g.
> a slice or a diagonal of a matrix is not a copy: it's a smart reference to
> the originals, and changing the values there will change the originals.
>
> This functionality is crucial to have for a good numerical language. So if
> compact arrays go in, please make sure that implementing such smart
> pointer arrays is possible, efficient and easy.
>
I agree with Tuomas' assessment. We would certainly love to dispense
with
the need for PDL if perl6 offered something along these lines.
But PDL is much more than an efficient memory representation for typed
N-D arrays. Above Jeremy suggests that most of the rest of the PDL core
is already proposed in one form or another.
Is that really true? There are a number of absolute conerstones
of functionality/semantics that are implemented in the current PDL Core
which any
replacement *must* have or improve upon to be really useful for us: PDL
threading, PDL dataflow + smart references (slicing), the PP code
generator to generate all the glue code for PDL functions and library
interfaces. This crucial functionality (that I don't see in any RFCs
yet) currently takes about 10000 lines of C and XS code for the core +
~7000 lines of perl for the code generator (which will probably have to
be rewritten as well). Without those features we will still need an
object that does what piddles do now and our own core.
There is nothing wrong with thinking about a rewrite of our core, a
tighter integration with the perl core and also getting some input from
principal perl gurus on how to throw in some more syntactical sugar.
However, I can't see the current PDL porters taking a large role in
implementing these things for a new perl simply since they are all *very
busy* with their own projects and can't invest the weeks of coding as
Tuomas did when he almost single-handedly wrote the current core (we are
still struggling with just *documenting* what PDL currently does). So I
am not sure how realistic it would be to just impose this task on the
perl6 implementers.
I mean, has anybody active in the perl6 thrust seriously worked with PDL
yet and come across those features that I am alluding to?
> PDL currently supports affine transformations but other kinds of
> transforms would be interesting. But to compile to C there need to be few
> types, unless a JIT compiler is included in the plans for perl 6.
And yes, the current PDL could certainly do with extension of its
features to objects representing sparse N-D arrays, non-rectangular
arrays, etc.
So my (personal) feeling is/was that from the PDL porters view
suggestions for syntactical changes that make integration of PDL in perl
an easier job (rather than a full PDL replacement) are currently our
most pragmatic contribution to the perl6 design effort.
Christian
