Well in PDL we called them 'piddles' for precisely this reason!
The problem is they ARE arrays, which perl already has, just with a
more compact storage and nicer representation.
And we ARE proposing to make them look like plain perl arrays remember!
So let's keep CALLING them arrays!
I sugg
Christian Soeller wrote:
> Buddha Buck wrote:
>
> > Tensor or Matrix
> > Multidimensional list
> > what should we call it?
> >
> > I'd vote for matrix myself. It's short and sweet
>
> Fine ;) Just have a section in the elusive overview RFC that defines
> what we mean by matrix, e.g. not only 2
Buddha Buck wrote:
> Tensor or Matrix
> Multidimensional list
> what should we call it?
>
> I'd vote for matrix myself. It's short and sweet
Fine ;) Just have a section in the elusive overview RFC that defines
what we mean by matrix, e.g. not only 2D objects of linear algebra.
With all the
> Karl Glazebrook wrote:
> > Can we not keep calling them matrices? They are just a special
> > case.
> >
> Normally I call them tensors, but this is only meaningful to a mathematics
> audience.
>
> I was using 'matrix' because both laypersons and mathematicians would know
> what the RFCs are ref
Karl Glazebrook wrote:
> Can we not keep calling them matrices? They are just a special
> case.
>
Normally I call them tensors, but this is only meaningful to a mathematics
audience.
I was using 'matrix' because both laypersons and mathematicians would know
what the RFCs are referring to. This wo
Buddha Buck wrote:
>
> 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
Jeremy Howard wrote:
>
> The RFCs I envisage are:
>
> - Overview of matrix RFCs
> - Notation for declaring and creating matrices
> - Notation for declaring sparse matrices
> - Notation for indexing matrices with a LOL as an index
> - ';' for slicing matrices
> - @#mat for getting the dimen
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
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
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
"
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
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;
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 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
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 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
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
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:
> 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
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
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
>What are these proposed radical changes? Ok, we have the slicing syntax
>issue and how to write 2D/3D matrices. Does it stop there? What are the
>other issues?
Actually nothing radical. I take it back. I am not disaggreeing with
current RFC's. And probably simple syntax parsing can be achieved w
>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?
Why do we have qw()?
Why do we have "=>" as an alias f
Jeremy Howard wrote:
>
> Baris wrote:
> > First of all I know that perl syntax has limitations and I understand why
> > the reasons of the new syntax proposals. And I think the syntax proposals
> > are pretty good if you accept the syntax limitations. I don't think any of
> > them do consider tha
Baris wrote:
> First of all I know that perl syntax has limitations and I understand why
> the reasons of the new syntax proposals. And I think the syntax proposals
> are pretty good if you accept the syntax limitations. I don't think any of
> them do consider that if somebody will write a PDL pro
Christian Soeller wrote:
> Jeremy Howard wrote:
>
> > 14,17;...20,29). What if we created a new operator ';' that works within
a
> > list that creates a cartesian product?:
> >
> > (10:20:2; 11:30:3); # Cartesian product of 10:20:2 and 11:30:3 as a
LOL
>
> A possible approach. Two issues: (1)
Ok. How about:
@a([$i,$j,$k], [$x,$y,$z]);
as far as I know this should be ok?
Baris.
*** REPLY SEPARATOR ***
On 8/31/00 at 3:02 PM Jeremy Howard wrote:
>Baris wrote:
>> > @a[[$i,$j,$k], [$x,$y,$z]]
>>
>> I think it is more readable if you have different type of parantheses:
>>
Hello,
First of all I know that perl syntax has limitations and I understand why
the reasons of the new syntax proposals. And I think the syntax proposals
are pretty good if you accept the syntax limitations. I don't think any of
them do consider that if somebody will write a PDL program he will u
Jeremy Howard wrote:
> 14,17;...20,29). What if we created a new operator ';' that works within a
> list that creates a cartesian product?:
>
> (10:20:2; 11:30:3); # Cartesian product of 10:20:2 and 11:30:3 as a LOL
A possible approach. Two issues: (1) others might argue that we should
use
Buddha Buck wrote:
> I'm willing to put this proposed compromise in RFC169v2 -- I like it,
> too -- but I'm not willing to put $a[$i][$j][$k] as equivilant to
> $a[[$i,$j,$k]] or $a[$i;$j;$k] into any RFC with me as the maintainer.
> I welcome Jeremy writing an RFC that does that, though.
>
This w
> > @a[[$i,$j,$k], [$x,$y,$z]]
>
> I think it is more readable if you have different type of parantheses:
> @a[($i,$j,$k), ($x,$y,$z)]
The trouble is that that already has a meaning (although perhaps not a
particularly useful one).
The list ($i,$j,$k) in scalar context evaluates to its final e
Christian Soeller wrote:
> I think a combination of yours and Budda's proposal is actually very
> nice:
>
> @a[10:20:2; 11:30:3]; # ; implies cartesian product of indices
> @a[10..20:2; 11..30:3]; # same with .. syntax
> @a[[10,20,2],[@index], [0,0,0]] # comma-separated index refs means
>
> @a[[$i,$j,$k], [$x,$y,$z]]
I think it is more readable if you have different type of parantheses:
@a[($i,$j,$k), ($x,$y,$z)]
Also:
[[$i,$j,$k], [$x,$y,$z]]
kind of resembles to creating a piddle where all these variables are the
values, whereas in your example of accessing two elements
@a[[$i,
> Jeremy Howard wrote:
>
> > Sorry--I need to correct this. The correct syntax for a list slice under my
> > proposal would actually be:
> >
> > @a[10:20:2][11:30:3]
> >
> > It needs the '@' of course since it's returning an array, and it needs to
> > use the standard LOL notation with the ex
Jeremy Howard wrote:
> Sorry--I need to correct this. The correct syntax for a list slice under my
> proposal would actually be:
>
> @a[10:20:2][11:30:3]
>
> It needs the '@' of course since it's returning an array, and it needs to
> use the standard LOL notation with the extension to multipl
Dan Sugalski wrote:
> On Thu, 31 Aug 2000, Jeremy Howard wrote:
> > Karl Glazebrook wrote:
> > > To access a single element we want
> > >
> > > $a[$i,$j,$k]
> > >
> > But this already means "the $i, $j, and $k" elements of a list. It is a
very
> > frequently used construct--I think that changing i
I wrote:
> Karl Glazebrook wrote:
> > for a slice we want
> >
> > $a[10:20:2, 11:30:3]
> >
> As opposed to:
>
> $a[[10:20:2], [11:30:3]]
>
Sorry--I need to correct this. The correct syntax for a list slice under my
proposal would actually be:
@a[10:20:2][11:30:3]
It needs the '@' of course s
On Thu, 31 Aug 2000, Jeremy Howard wrote:
> > To access a single element we want
> >
> > $a[$i,$j,$k]
> >
> But this already means "the $i, $j, and $k" elements of a list. It is a very
> frequently used construct--I think that changing it will be impossible, and
> that creating a new data type th
> 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 access a single element we want
>
> $a
A comment:
we are after SIMPLE syntax. This means like C, Fortran, IDL and Matlab.
Perl is about working like most people expect.
To access a single element we want
$a[$i,$j,$k]
for a slice we want
$a[10:20:2, 11:30:3]
Replace "," and ":" with your favourite punctuation stop, and "[]" with
40 matches
Mail list logo
