Baris wrote:
> >We're talking about how we'll write Perl 6 programs, not PDL programs. We
> >need to ensure that the syntax we create is Perlish.
> Aggreed.
> But there is nothing wrong with making the syntax user friendly, or am I
> totally missing what perl is?
Perl is user-friendly to Perl use
Jeremy Howard wrote:
> The 1st implementation of Perl 6 may not provide all the optimisations we've
> come to expect from our data crunching language of choice. For this reason
> maybe PDL will continue to exist independently in Perl 6 at least for a
> while, although a fair bit of rewriting will
Baris wrote:
> PDL has PP, which is very nice, but you still need to compile the code (Is
> this correct? Is there any documentation about how to compile pp code?).
There is. It's towards the end of the PP manpage.
> sub sumit{
>my @a = @_;
> $tmp = 0;
>
Baris wrote:
> Looping through the matrix elements is probably most common thing people
do
> in matrix computation. And because of some weird reason I am not aware of,
> the only way to do this efficiently is to write your program in C. So
> everybody I know sooner or later switches to C because o
On Thu, 31 Aug 2000 11:20:25 +1100, Jeremy Howard wrote:
>My hope is that we can have a single set of frozen RFCs in a month's time,
>with incompatible or redundant RFCs withdrawn.
>In the end, I trust Larry to make good in-or-out decisions if we give him
>good input.
Personally, I would like
Bart Lateur wrote:
> Personally, I would like to have Larry's fiat *before* trying to iron
> out the incompatibilities. It could be that you throw away something
> that Larry would approve of, and keep something he doesn't like.
I'd vote to go for what we think is the best compromise. If Larry
i
Jeremy Howard wrote:
> @b = (1,2,3);
> @c = (2,4,6);
> @d = (-2,-4,-6);
> $sum = reduce ^_+^_, @b * @c + @d;
>
> should be evaluated as if it read:
>
> $sum = 0;
> $sum += $b[$_] * $c[$_] + $d[_] for (0..$#a-1));
>
> That is, no temporary list is created, and only one loop is requi
Jeremy Howard wrote:
> We're talking about how we'll write Perl 6 programs, not PDL programs. We
> need to ensure that the syntax we create is Perlish. It needs to fit in with
> the rest of the language--our proposals won't get through if programs look
> quite different in sections just because ar
Jeremy Howard wrote:
My plan for this list is to strongly encourage RFC maintainers to work
> together to remove conflicts and incompatibilities from their RFCs. This
> will sometimes require retiring a number of RFCs and writing a new
> consolidated one.
>
> My hope is that we can have a single
Jeremy Howard wrote:
>
> > we are after SIMPLE syntax. This means like C, Fortran, IDL and Matlab.
> > Perl is about working like most people expect.
> >
> Yes, we are after simple syntax. We also want to make to hard things
> possible. Therefore we want a syntax that is also flexible.
>
> > To
At 08:52 AM 8/31/00 -0400, Karl Glazebrook wrote:
>Jeremy Howard wrote:
> >
> > > we are after SIMPLE syntax. This means like C, Fortran, IDL and Matlab.
> > > Perl is about working like most people expect.
> > >
> > Yes, we are after simple syntax. We also want to make to hard things
> > possible
This is beginning to sound like something I would support.
Heavens are we approaching some sort of consensus.
This also addresses one pain in current PDL which is the
difficulty of multi-dim indexing.
Buddha Buck wrote:
>
> Here is a quick summary of the proposal:
>
> In the raw, arrays can b
At 12:09 PM 8/31/00 -0400, Karl Glazebrook wrote:
>This is beginning to sound like something I would support.
>
>Heavens are we approaching some sort of consensus.
The one thing the proposal I mentioned doesn't cover is Jeremy's desire to
have $a[$i][$j][$j] be synonymous with $a[[$i,$j,$k]], an
If I'm stepping on toes here, please tell me...
Here are some suggestions for some upcoming language-data RFC's I'm
thinking of writing:
RFC 169v2: Matrix Indexing
Cover my $matrix[$x;$y;$z] syntax
Add Jeremy's $matrix[$listref] syntax
Discuss why two ways of doing it.
Move inde
Karl Glazebrook wrote:
> This also addresses one pain in current PDL which is the
> difficulty of multi-dim indexing.
I like it, too ;)
> > print $a[[0,0,0]];# literal ref list
> > print $a[0;0;0]; # literal singleton ; list
> > print $a[[$y,$y,$y]]; # variable-based ref list
> > print
At 08:10 AM 9/1/00 +1200, Christian Soeller wrote:
>No, at least 18. One more piece of semantics that would be appreciated
>is optional omission of trailing dimensions in slices, e.g. for a 3-dim
>@a:
>
> @a[0:1] == @a[0:1;] == @a[0:1;;]
Would you go for:
@a[$first;*];
@a[*;$last];
@a[$first;
Buddha Buck wrote:
> RFC X+2: Retrieving Matrix dimensions
> Present @#matrix as analogous to $#array
> Discuss what $#matrix should return, as well as @#array
> What is @matrix in scaler context? (undef, anyone?)
Number of elements? For sparse matrices number of non-zero elements?
Buddha Buck wrote:
> Would you go for:
>
> @a[$first;*];
> @a[*;$last];
> @a[$first;*;$last]?
>
> Say yes, and I'll add it tonight!
Nice! I'd go as far as implying a trailing ';*' if omitted.
>
> I'm unsure if @a[*;$middle;*] has any reasonable interpretation.
Probably just croak. Unless so
Jeremy Howard wrote:
> That's true. I still think it's confusing to have such similar syntaxes mean
> such different things. I'd also like to be able to say:
>
> @a[[$i,$j,$k], [$x,$y,$z]]
>
> to get two points.
Just in case anyone isn't aware of this:
using a "stuff'em into hash keys" N-d
Christian Soeller wrote:
>
> No, at least 18. One more piece of semantics that would be appreciated
> is optional omission of trailing dimensions in slices, e.g. for a 3-dim
> @a:
>
> @a[0:1] == @a[0:1;] == @a[0:1;;]
>
> Christian
this would be the * in my proposal made in mail w/ subject
"
"David L. Nicol" wrote:
>
> @a["$i $j $k","$a $y $z"] # two points in DN n-dim syntax
One problem that immediately jumps out at me is how to do this:
@a[[@x], [@y]];
That is, dynamically get your indices. The above seems ok when you know
them in advance (at least what variables
Nathan Wiger wrote:
>
> "David L. Nicol" wrote:
> >
> > @a["$i $j $k","$a $y $z"] # two points in DN n-dim syntax
>
> One problem that immediately jumps out at me is how to do this:
>
>@a[[@x], [@y]];
>
> That is, dynamically get your indices. The above seems ok when you know
Christian Soeller wrote:
> No, at least 18. One more piece of semantics that would be appreciated
> is optional omission of trailing dimensions in slices, e.g. for a 3-dim
> @a:
>
> @a[0:1] == @a[0:1;] == @a[0:1;;]
>
I'd rather see the ';' be required, but the '(0..)' not be required, so you
cou
"David L. Nicol" wrote:
>
> > One problem that immediately jumps out at me is how to do this:
> >
> >@a[[@x], [@y]];
>
> I think I dealt with that in the next paragraph, suggesting
>
> @a["@x","@y"]
Well, this is not bad, only it's not without its problems. Say you
wanted to get you
Jeremy Howard wrote:
> I'd rather see the ';' be required, but the '(0..)' not be required, so you
This is not good! There are a lot of routines where it is very useful to
specify a slice as
@a[0]
that should work regardless how many dimensions @a really has. There are
many instances in PDL
Buddha Buck wrote:
> If I'm stepping on toes here, please tell me...
>
See my other message today for the RFCs I'm thinking of writing. Buddha--you
and I should probably sought out offline which of us will write what RFC.
> RFC 169v2: Matrix Indexing
> Cover my $matrix[$x;$y;$z] syntax
>
At 05:35 PM 8/31/00 +, David L. Nicol wrote:
>Buddha Buck wrote:
> > > The array
> > > syntax would also be useful in multi-dimensional arrays.
> >
> > That is if multi-dimensional arrays are implemented as lists-of-lists,
> > which they might not be.
>
>Even if they aren't implemented as lol,
Peter Scott wrote:
>
> >Having the
> >indices in one place saves a lot of characters. Compare
> >
> > $r->{{qw(a b c d e f g h)}}
> >
> >versus
> >
> > $r->{a}->{b}->{c}->{d}->{e}->{f}->{g}->{h}
>
> But I would compare it to
>
> $r->{a}{b}{c}{d}{e}{f}{g}{h}
>
> which is
Buddha Buck wrote:
> At 05:35 PM 8/31/00 +, David L. Nicol wrote:
> >Buddha Buck wrote:
> > > > The array
> > > > syntax would also be useful in multi-dimensional arrays.
> > >
> > > That is if multi-dimensional arrays are implemented as lists-of-lists,
> > > which they might not be.
> >
> >Ev
Hello,
Looping through the matrix elements is probably most common thing people do
in matrix computation. And because of some weird reason I am not aware of,
the only way to do this efficiently is to write your program in C. So
everybody I know sooner or later switches to C because of the speed is
Christian Soeller wrote:
> There might still be a need for something for those people who need FFTs
> and work on really large blocks of data. The hope would be that a perl6
> PDL would fill such a gap and be more perlish than it is now. But again
> concrete syntax ideas are needed along with a cl
31 matches
Mail list logo
