develooper Front page | perl.perl6.language.data | Postings from August 2000

a strategy?

From:
Christian Soeller
Date:
August 30, 2000 17:18
Subject:
a strategy?
Message ID:
39AD96DF.BCC31AB0@auckland.ac.nz
I have been thinking about what has come up on this list so far and was
wondering if there isn't a strategy so that we all benefit and come up
with a number of very strong proposals. The following seems to be a
constructive approach to me:

1) There is nothing wrong with having many RFCs

What remains is identifying which RFCs deal with very similar issues and
identify conflicts between them. They can hopefully be resolved on this
list. The next step is to update these RFCs so that conflicts are either
removed or clearly pointed out with extensive crossreferencing to the
relevant RFCs and a clear statement why this author sees it this way and
not the other.

That should leave us with a set of RFCs that can be read by one person
to quickly get an idea what the consensus and what the open questions
are.

2) The current PDL view versus possibly a slightly different view for
the suggested n-dim arrays

It seems not unlikely that there will (at least initially) be a
situation in perl6 where we might have both the new nD arrays and PDL
objects. I wouldn't think there is anything wrong with that if we make
it easy to switch from one presentation to the other. Basically, I'd
imagine you'd be able to say

  $pdl = pdl @nDarray;
  @array = $pdl->nD;
  @res = @nD * $pdl->nD;
  $res = @nD * $pdl; # who wins? ;)

And to be cool they would share the same compact data, so $pdl++ will
actually increment @array; they are just slightly different views of the
same data. I'd see that as very perlish: if you want to view them as
(scalar) objects use the PDL view, if you wan't to see them as arrays
use the nD array view. The thing I would like to make sure is that
slicing syntax and operator behaviour would be virtually identical so
that a user familiar with one could easily learn the other. If that
means that PDL will have to change its slicing syntax that's fine.

3) Different programming styles and current PDL.

Most people on this list (apart from the pdl-porters ;) seem to favour a
slightly different programming style than what we have in current PDL.
Also, some people have mentioned that PDL is awkward to program right
now. I personly would have hoped that apart from all the suggestions how
perl6 should fix this I could go away with some lessons on how to
improve PDL now to make it more user friendly while we're waiting for
perl6. Here it is absolutely crucial that people don't stay general but
give conrete examples and say:

   look, this is not nice code .... I would rather write this...

Then we can see if we can adopt this other style for PDL NOW. And that
leads to my fourth point:

4) Code up some actual algorithms in the new virtual num-perl6

To see how useful our current suggestions are we should pick a number of
real-world problems, e.g. Levenberg-Marquardt curve fitting or whatever
and write scripts in the virtual code to see what it would actually look
like. That's also a good way to identify missing bits and pieces in our
suggestions.

So Karl or I might code up how we might envisage that in an improved
PDL, Jeremy, Budda or so use might use an approach that is more inspired
by functional programming. Along the way we might discover that we
really need to specify additional detail or a current syntax proposal
leads to awkward code, etc.
Also, I might go home and say: yeah, this piece of code by Jeremy (say)
looks really awesome and is much better than what PDL can offer.

How does that sound?

  Christian



nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About