Re: N-dimensional arrays and compiler support
Daniel (), Stefan ():
1. The semicolon operator would allow Perl 6 to support N-dimensional
arrays... How would one iterate over that type of array?
my num @matrix[ 10 ; 10 ; 10 ];
I ask because a natural extension is to add arithmetic operators and
you have the beginnings of a Matlab-like array language.
I've started trying to implement S09 things this month, and this is
actually one of the big questions that came up for me. I raised it
on IRC earlier (which is much more active than p6l, fwiw) and I don't
think we actually arrived at a definite answer.
There are three obvious choices for what 'for @matrix { }' means:
* Iterate over slices that fix the leftmost index
* Iterate over all elements in lexicographic order
* Die
I'm currently thinking of the first, because it allows
(map {$_}, @matrix)[0] to mean the same thing as @matrix[0]. But it's
likely there are other nice considerations.
My vote also falls on alternative (1). S09 already has wording on
indexing being the same for shaped arrays and nested arrays:
For all multidimensional array types, it is expected that cascaded
subscripts:
@x[0][1][42]
@x[0..10][1,0][1,*+2...*]
will either fail or produce the same results as the equivalent
semicolon subscripts:
@x[0;1;42]
@x[0..10; 1,0; 1,*+2...*]
We could extrapolate this to give support for alternative (1).
Also, though my memory may be playing tricks on me here, I believe it
is consistent with what APL does.
2. Do you think Rakudo is likely to get support for N-dimensional
arrays in... say... the next year or so?
No comment. If pmichaud stays alive and well, anything is possible.
The shaped arrays/hashes parts of S09 have been in the planning
stages a long time in Rakudo. They've had to wait for better MOP and
better native-types handling (which is another part of S09), but now
the time for shaped arrays/hashes is surely here. If jnthn or pmichaud
hasn't started digging into them by the time I finish the macro grant,
I likely will.
We know shaped arrays/hashes are a slightly murky area in the spec.
It's not as bad as, say, S16 (I/O) or S17 (concurrency), but it's
probably slightly inconsistent simply due to its sheer ambitiousness.
Part of what hinders its imminent implementation is that anyone who
picks it up will have to ask piercing questions such as the above one
for quite a while, then form a mental model of what needs to be
implemented, then implement it. After that has happened, we'll look at
S09 and throw out a bunch of things that proved to be simplistic,
naive, or plain wrong.
Still, I look forward to those parts being implemented. In some vague
sense, shaped arrays/hashes are just sugar, but I believe they'll
form an integral part in idiomatic Perl 6, and provide a real edge
over corresponding unsugared Perl 5 code, even in fairly simple
scripts.
// Carl
Re: N-dimensional arrays and compiler support
On 23 March 2012 12:55, Carl Mäsak cma...@gmail.com wrote: The shaped arrays/hashes parts of S09 have been in the planning stages a long time in Rakudo. They've had to wait for better MOP and better native-types handling (which is another part of S09), but now the time for shaped arrays/hashes is surely here. If jnthn or pmichaud hasn't started digging into them by the time I finish the macro grant, I likely will. Cool. Part of me wants to volunteer to help, but I know that I just don't have time... Still, I look forward to those parts being implemented. In some vague sense, shaped arrays/hashes are just sugar, but I believe they'll form an integral part in idiomatic Perl 6, and provide a real edge over corresponding unsugared Perl 5 code, even in fairly simple scripts. My work is probably not typical, but I would really like to see this feature. Most of my work is numerical computation. My workhorse language is Fortran 2008, but I always have either Octave or Python running on a shell for quick calculations and some times to experiment with algorithms. Thing is, I don't like Octave and I don't like Python (and I don't like PDL). Now that I've discovered the Rakudo shell, Perl 6 has basically replaced Python for me. I have considered writing a minimalist numerical array class for Perl 6 so I could replace Octave. I gave it a go a few days ago, but I quickly got stuck on how to deal with multi-dimensional arrays. I might come back to this in the summer if I have more time then. Cheers, Daniel. -- I'm not overweight, I'm undertall.
N-dimensional arrays and compiler support
Hey, I have a few slightly related questions: 1. The semicolon operator would allow Perl 6 to support N-dimensional arrays... How would one iterate over that type of array? my num @matrix[ 10 ; 10 ; 10 ]; I ask because a natural extension is to add arithmetic operators and you have the beginnings of a Matlab-like array language. 2. Do you think Rakudo is likely to get support for N-dimensional arrays in... say... the next year or so? 3. Does anyone here know much about Niecza? Can you compare it with Rakudo? I am already familiar with the feature support page (http://perl6.org/compilers/features) so I am leaving the question intentionally vague. I'd be interested in anything that you think is interesting (e.g. speed, development style, progress, whatever). Cheers, Daniel. -- I'm not overweight, I'm undertall.
Re: N-dimensional arrays and compiler support
On Thu, Mar 22, 2012 at 11:14:54PM +0100, Daniel Carrera wrote:
Hey,
I have a few slightly related questions:
1. The semicolon operator would allow Perl 6 to support N-dimensional
arrays... How would one iterate over that type of array?
my num @matrix[ 10 ; 10 ; 10 ];
I ask because a natural extension is to add arithmetic operators and
you have the beginnings of a Matlab-like array language.
I've started trying to implement S09 things this month, and this is
actually one of the big questions that came up for me. I raised it
on IRC earlier (which is much more active than p6l, fwiw) and I don't
think we actually arrived at a definite answer.
There are three obvious choices for what 'for @matrix { }' means:
* Iterate over slices that fix the leftmost index
* Iterate over all elements in lexicographic order
* Die
I'm currently thinking of the first, because it allows
(map {$_}, @matrix)[0] to mean the same thing as @matrix[0]. But it's
likely there are other nice considerations.
2. Do you think Rakudo is likely to get support for N-dimensional
arrays in... say... the next year or so?
No comment. If pmichaud stays alive and well, anything is possible.
3. Does anyone here know much about Niecza? Can you compare it with
Rakudo? I am already familiar with the feature support page
(http://perl6.org/compilers/features) so I am leaving the question
intentionally vague. I'd be interested in anything that you think is
interesting (e.g. speed, development style, progress, whatever).
For some reason it's much less suprising; I almost never have to guess
what niecza will do with a given piece of code.
Seriously, relative to Rakudo:
Performance: Uses less memory, compiles comparably fast, used to
be much faster at runtime but the gap has narrowed considerably.
Platform: Rakudo/Parrot requires a system with a C89 compiler and a
sufficiently 386-like processor (in particular, it wants a flat address
space and equal size code and data pointers). Niecza requires a CLR
implementation (developed on Mono, tested on Microsoft .NET).
Rakudo can use C libraries, Niecza can use CLR libraries.
Features: Idiosyncratic variance. Niecza is still generally ahead on
regex support and a few other odds and ends. Rakudo currently has the
edge on macros, list behavior, native types, the MOP, and working
libraries.
Cheers,
Daniel.
-Stefan
signature.asc
Description: Digital signature
