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
