> @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,$j,$k], [$x,$y,$z]]
the variables are actually indices, not the values. Two similar syntaxes,
two different meanings open to possible mistakes and confusion.
More on syntax for creating pdls:
Can we just get rid of unnecessary commas. Spaces should be good enough:
$p = pdl [[1 2 3][4 5 6]];
Also aren't there too many and confusing "[" and"]"s in the syntax. This
makes difficult and unreadable to create matrices by hand? For an 3x8
matrix (without commas):
$p = pdl [[1 2 3][4 5 6][4 5 6][6 3 3][2 3 5][3 5 5][3 5 5][2 2 2]];
Do you really feel that this looks like a 2-d matrix. It feels like a 3-d
matrix to me when I first see it. This is very ugly syntax and doesn't fit
human perception. Even though we can't visualize 10-d spaces, we are pretty
good at visualizing 2-d objects. So this kind of complicated syntax can be
suitable for n-d representation but the first two dimensions should be more
natural.
Easier syntax would be:
$p = pdl [1 2 3, 4 5 6, 4 5 6, 6 3 3, 2 3 5, 3 5 5, 3 5 5, 2 2 2];
or
$p = pdl [1 2 3; 4 5 6; 4 5 6; 6 3 3; 2 3 5; 3 5 5; 3 5 5; 2 2 2];
Now if you are wondering how this would scale to multiple dimensions since
this is specific to 2-d, here is a 3x8x2 matrix:
$p = pdl [1 2 3; 4 5 6; 4 5 6; 6 3 3; 2 3 5; 3 5 5; 3 5 5; 2 2 2][1 2 3; 4
5 6; 4 5 6; 6 3 3; 2 3 5; 3 5 5; 3 5 5; 2 2 2];
or better written:
$p = pdl [1 2 3; 4 5 6; 4 5 6; 6 3 3; 2 3 5; 3 5 5; 3 5 5; 2 2 2]
[1 2 3; 4 5 6; 4 5 6; 6 3 3; 2 3 5; 3 5 5; 3 5 5; 2 2 2];
Is this a limited or confusing syntax? No. Here instead of assuming that
vectors are the smallest building blocks, I assumed 2-d matrices are the
building blocks and vectors are just 2-d matrices with the second dimention
equal to zero. Well here is how current synta will handle a column vector
anyway:
$p = pdl [[3], [4], [2], [3], [4], [2], [3], [4], [2]];
and my suggested syntax:
$p = pdl [3 ; 4 ; 2 ; 3 ; 4 ; 2 ; 3 ; 4; 2];
As I mentioned we can visualize 2-d easily so there is nothing wrong to use
a special syntax for the first two dimensions. Isn't this very perlish?
Also as I mentioned before %90 or maybe more of the time pdl will be used
for 1-d or 2-d calculations.
Baris.
*********** REPLY SEPARATOR ***********
On 8/31/00 at 1:06 PM Jeremy Howard wrote:
>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 it will be
impossible,
>and
>> > that creating a new data type that acts contrary to this would be
highly
>> > confusing.
>>
>> It doesn't, though. It actually means the $k element of the array
$a--for
>> the $i, $j, and $k elements you'd need a @ in front of the slice.
>>
>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.
>
>> <...>
>> Either way, I expect the parser would know what you were doing and Do
The
>> Right Thing, though personally I'd rather we didn't overload the LOL
>> syntax this way. (We'll do it if it comes to that, though) You might
>> consider an alternative as part of the RFC that uses new syntax
>> rather than overloading the old.
>>
>I'm not sure I following... We're not overloading the old notation, but
>instead:
>
> - Implementing it more efficiently if the data fits a hypercube structure
> - Adding notation to get at elements more easily:
> * @a[[$i,$j,$k], [$x,$y,$z]]
> * @a[$i,$x][$j,$y][$k,$z]
>
>> This is just personal preference--I grew up programming in languages
that
>> had real multidimensional arrays, and I'd just as soon we added them to
>> perl for real. (Real being in a user-visible sense--I know we'll do it
for
>> real under the hood)
>>
>I want them 'for real' too, both in the syntactic and implementation
sense.
>Just because they happen to support the LOL syntax, I don't yet see how
they
>are less than 'real'. They can be indexed directly, sliced, iterated
through
>any dimension, and so forth. The only difference I can see is whether we
>have a type prefix in addition to '@'. What are the syntactic features you
>are envisioning that would make n-dim arrays more user visibly real?
*********** REPLY SEPARATOR ***********
On 8/31/00 at 1:06 PM Jeremy Howard wrote:
>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 it will be
impossible,
>and
>> > that creating a new data type that acts contrary to this would be
highly
>> > confusing.
>>
>> It doesn't, though. It actually means the $k element of the array
$a--for
>> the $i, $j, and $k elements you'd need a @ in front of the slice.
>>
>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.
>
>> <...>
>> Either way, I expect the parser would know what you were doing and Do
The
>> Right Thing, though personally I'd rather we didn't overload the LOL
>> syntax this way. (We'll do it if it comes to that, though) You might
>> consider an alternative as part of the RFC that uses new syntax
>> rather than overloading the old.
>>
>I'm not sure I following... We're not overloading the old notation, but
>instead:
>
> - Implementing it more efficiently if the data fits a hypercube structure
> - Adding notation to get at elements more easily:
> * @a[[$i,$j,$k], [$x,$y,$z]]
> * @a[$i,$x][$j,$y][$k,$z]
>
>> This is just personal preference--I grew up programming in languages
that
>> had real multidimensional arrays, and I'd just as soon we added them to
>> perl for real. (Real being in a user-visible sense--I know we'll do it
for
>> real under the hood)
>>
>I want them 'for real' too, both in the syntactic and implementation
sense.
>Just because they happen to support the LOL syntax, I don't yet see how
they
>are less than 'real'. They can be indexed directly, sliced, iterated
through
>any dimension, and so forth. The only difference I can see is whether we
>have a type prefix in addition to '@'. What are the syntactic features you
>are envisioning that would make n-dim arrays more user visibly real?
