Re: RFC 272 (v1) Arrays: transpose()
Jeremy: you should look at the PDL mv() and xchg() methods and factor this into your thinking! Karl
Re: RFC 231 (v1) Data: Multi-dimensional arrays/hashes and slices
Ilya Zakharevich wrote:
But with Fortran such things are not *needed*. Compilers are smart
enough to convert (equivalents to)
map 3*$_, 34..67
This is true, but easier (and less buggy) to say what you
exactly what you mean. 102:201:3
Anyway the idea has been proposed, it won't break Perl, we'll see
what happens.
f(3*@a)
would typically be a list context - and suddently instead of 3*(1+$#a)
you get Cmap 3*$_, @a.
This is true, what I would propose is we declare 3*(1+$#a) outmoded and
always have it mean Cmap 3*$_, @a in all contexts.
This of course will break perl5 code. Note mine because I always say
3*scalar(@a) because 3*@a does not look like 3*(1+$#a) to me. I don't
know how many people would depend on that feature.
There is also the problenm that we are arguing somewhat in a vacuum
as we don't know how radical perl6 (in terms of syntax changes) will
be.
Anyhow the various proposals are out there, we'll see what happens.
Why? Currently you can make them look like references to array. See
Math::Pari for an implementation. Overloading '@{}' gives yet another
way to do this.
True but the user has to remember 'owe I am now using a special PDL
array which means I have to always use a reference to it rather than
treat it like a perl array'. Not good.
It's really hard to explain why people should use @x[1..10] for
perl arrays and $x-slice("1:10") for PDL arrays!
Use
$x-[1..10]
for both.
This is true, but inelegant. If perl @x arrays are not considered useful
why not get rid of them and always use references?
Karl
Re: RFC 231 (v1) Data: Multi-dimensional arrays/hashes and slices
On Fri, Sep 22, 2000 at 11:17:40AM -0400, Karl Glazebrook wrote:
[Cryptocontext is:]
f(3*@a)
would typically be a list context - and suddently instead of 3*(1+$#a)
you get Cmap 3*$_, @a.
This is true, what I would propose is we declare 3*(1+$#a) outmoded and
always have it mean Cmap 3*$_, @a in all contexts.
You are trading a frequently used shortcut @a == 1 + $#a for a
rarely-used-but-beautiful/intuitive semantic. I'm not sure it is a win.
Moveover,
$x = 3 * @_;
suddently being equivalent to
$x = @_;
does not look very promising...
Why? Currently you can make them look like references to array. See
Math::Pari for an implementation. Overloading '@{}' gives yet another
way to do this.
True but the user has to remember 'owe I am now using a special PDL
array which means I have to always use a reference to it rather than
treat it like a perl array'. Not good.
No, you do not use "a special PDL array", you use "a vector".
A subtle change in wording - and no conflict.
This is true, but inelegant. If perl @x arrays are not considered useful
why not get rid of them and always use references?
Actually, this is what Perl is using internally (they are
softreferences==globs, but who cares?).
Ilya
Re: RFC 272 (v1) Arrays: transpose()
Karl Glazebrook wrote: you should look at the PDL mv() and xchg() methods and factor this into your thinking! Actually, the RFC is based on PDL's xchg()! I forgot to document using negative numbers to count from the last dimension--I'll add that into the next version. Are there any other differences with xchg() that you think would be useful? I haven't used mv() before, but now I look at it I can see it's pretty interesting. Is this used much? If we add it to the RFC, do you think we'd want a separate function, or add another arg to transpose: transpose([$a,$b], 0, @arr); # xchg transpose([$a,$b], 1, @arr); # mv
Re: RFC 272 (v1) Arrays: transpose()
Jeremy Howard wrote: Karl Glazebrook wrote: you should look at the PDL mv() and xchg() methods and factor this into your thinking! Actually, the RFC is based on PDL's xchg()! I forgot to document using negative numbers to count from the last dimension--I'll add that into the next version. Are there any other differences with xchg() that you think would be useful? I haven't used mv() before, but now I look at it I can see it's pretty interesting. Is this used much? If we add it to the RFC, do you think we'd want a separate function, or add another arg to transpose: transpose([$a,$b], 0, @arr); # xchg transpose([$a,$b], 1, @arr); # mv Think about threading sumover sums a piddle along axis 0, e.g. a 3x4x5 piddle - 4x5 now we can use sumover $x-mv(2,0) to sum along axis 2 instead. we get a 3x4 piddle Think about this for N-dims - mv can be used to bring any dimension to the front. Easier than to use xchg - no need to worry about which axis is being swapped with. OK sumover is equivalent to NumPy's add.reduce But we also have medover and NumPy has no median.reduce medover and sumover are trivial PP functions and mv has no memory copy overhead Karl
Re: RFC 231 (v1) Data: Multi-dimensional arrays/hashes and slices
Ilya Zakharevich wrote: You are trading a frequently used shortcut @a == 1 + $#a for a rarely-used-but-beautiful/intuitive semantic. I'm not sure it is a win. It's now boiling down to a matter of opinion and we'll have to agree to differ. Of course I use array arithmetic all the time as a heavy PDL user. Moveover, $x = 3 * @_; suddently being equivalent to $x = @_; does not look very promising... But would it not be easy to catch and warned by a p5tp6 converter? No, you do not use "a special PDL array", you use "a vector". A subtle change in wording - and no conflict. sure, but vector to me means 1D and also some sort of transformation properties whereas a PDL array is just a N-dim square container. anyway semantics - we call them 'piddles' which is moderately amusing but inelegant. This is true, but inelegant. If perl @x arrays are not considered useful why not get rid of them and always use references? Actually, this is what Perl is using internally (they are softreferences==globs, but who cares?). Hmm Karl
Re: RFC 231 (v1) Data: Multi-dimensional arrays/hashes and slices
On Fri, Sep 22, 2000 at 05:24:55PM -0400, Karl Glazebrook wrote: It's now boiling down to a matter of opinion and we'll have to agree to differ. Of course I use array arithmetic all the time as a heavy PDL user. ...Do you say you are confused by using vectors (=scalars) instead of arrays? Moveover, $x = 3 * @_; suddently being equivalent to $x = @_; does not look very promising... But would it not be easy to catch and warned by a p5tp6 converter? Why converters? I'm discussing Perl6 now, not converters. No, you do not use "a special PDL array", you use "a vector". A subtle change in wording - and no conflict. sure, but vector to me means 1D and also some sort of transformation properties whereas a PDL array is just a N-dim square container. An N-dim container is just a vector which contains vectors... Ilya
Re: RFC 231 (v1) Data: Multi-dimensional arrays/hashes and slices
Ilya Zakharevich wrote: Moveover, $x = 3 * @_; suddently being equivalent to $x = @_; does not look very promising... Why are these equivalent? RFC 82 only applies in list context. Am I missing something?
Re: RFC 231 (v1) Data: Multi-dimensional arrays/hashes and slices
On Sat, Sep 23, 2000 at 09:52:51AM +1100, Jeremy Howard wrote: $x = 3 * @_; suddently being equivalent to $x = @_; does not look very promising... Why are these equivalent? RFC 82 only applies in list context. Am I missing something? Yes, the proposal to make map 3*$_ semantic to work in a scalar context too (to avoid cryptocontext). Ilya
Re: RFC 231 (v1) Data: Multi-dimensional arrays/hashes and slices
Karl Glazebrook wrote:
Ilya Zakharevich wrote:
You are trading a frequently used shortcut @a == 1 + $#a for a
rarely-used-but-beautiful/intuitive semantic. I'm not sure it is a win.
It's now boiling down to a matter of opinion and we'll have to agree to
differ. Of course I use array arithmetic all the time as a heavy PDL
user.
It's not just for number-crunchers either. Array notation greatly simplifies
many frequently used operations. For instance (from RFC 82):
quote
@people = ('adam', 'eve ', 'bob ');
@scores = (7,9,5); # Score for each person
@histogram = '#' x @scores; # Returns ('xxx','x','x')
print join("\n", @people . ' ' . @histogram);
adam xxx
eve x
bob x
/quote
Array notation is not 'rarely used' in languages that support it--in fact,
operations are applied to arrays and lists at least as often as scalars in
most code I see written for Mathematica, J, PDL, and so forth.
Re: RFC 231 (v1) Data: Multi-dimensional arrays/hashes and slices
On Sat, Sep 23, 2000 at 10:01:11AM +1100, Jeremy Howard wrote:
It's now boiling down to a matter of opinion and we'll have to agree to
differ. Of course I use array arithmetic all the time as a heavy PDL
user.
It's not just for number-crunchers either. Array notation greatly simplifies
many frequently used operations. For instance (from RFC 82):
@people = ('adam', 'eve ', 'bob ');
@scores = (7,9,5); # Score for each person
@histogram = '#' x @scores; # Returns ('xxx','x','x')
print join("\n", @people . ' ' . @histogram);
adam xxx
eve x
bob x
Are you trying to convince me/us that is going to be used often?
Array notation is not 'rarely used' in languages that support it--in fact,
operations are applied to arrays and lists at least as often as scalars in
most code I see written for Mathematica, J, PDL, and so forth.
a) You can *already* use vectors as scalars in Perl;
b) What we are discussing is Perl, not Mathematica, J, PDL, and so
forth. These languages have a very narrow niche.
Ilya
Re: RFC 231 (v1) Data: Multi-dimensional arrays/hashes and slices
Ilya Zakharevich wrote: Are you trying to convince me/us that is going to be used often? Yes, I am. You made the unsupported statement that array operations are rarely used. I'm suggesting otherwise (although to say that they're rarely used in Perl 5 is a tautology, of course!). Array notation is not 'rarely used' in languages that support it--in fact, operations are applied to arrays and lists at least as often as scalars in most code I see written for Mathematica, J, PDL, and so forth. a) You can *already* use vectors as scalars in Perl; That's not what RFC 82 is proposing. b) What we are discussing is Perl, not Mathematica, J, PDL, and so forth. These languages have a very narrow niche. That's because few such languages provide strong general purpose programming features as well. They are either limited maths-oriented languages (like Mathematica) or add-ons to general purpose languages that aren't fully integrated (Python/NumPy; Perl/PDL; C++/Blitz++). Many Perl users operate on lists of data. Requiring explicit loops every time a programmer wants to operate on a list is asking the programmer to fit in with how a computer thinks. That's not right.
Re: RFC 231 (v1) Data: Multi-dimensional arrays/hashes and slices
On Sat, Sep 23, 2000 at 10:41:07AM +1100, Jeremy Howard wrote: a) You can *already* use vectors as scalars in Perl; That's not what RFC 82 is proposing. Who cares? This already works... b) What we are discussing is Perl, not Mathematica, J, PDL, and so forth. These languages have a very narrow niche. That's because few such languages provide strong general purpose programming features as well. They are either limited maths-oriented languages (like Mathematica) or add-ons to general purpose languages that aren't fully integrated (Python/NumPy; Perl/PDL; C++/Blitz++). Many Perl users operate on lists of data. Requiring explicit loops every time a programmer wants to operate on a list is asking the programmer to fit in with how a computer thinks. That's not right. Well, this is your opinion agains mine... ;-) Ilya
Re: RFC 231 (v1) Data: Multi-dimensional arrays/hashes and slices
Ilya Zakharevich wrote: On Fri, Sep 22, 2000 at 05:24:55PM -0400, Karl Glazebrook wrote: It's now boiling down to a matter of opinion and we'll have to agree to differ. Of course I use array arithmetic all the time as a heavy PDL user. ...Do you say you are confused by using vectors (=scalars) instead of arrays? I'm not having a problem with that personally but *many* users of PDL have complained about being confused by this. They assume ndim == array == perl array. Christian
Re: RFC 272 (v1) Arrays: transpose()
Jeremy Howard wrote:
Karl Glazebrook wrote:
you should look at the PDL mv() and xchg() methods
and factor this into your thinking!
Actually, the RFC is based on PDL's xchg()! I forgot to document using
negative numbers to count from the last dimension--I'll add that into the
next version. Are there any other differences with xchg() that you think
would be useful?
I haven't used mv() before, but now I look at it I can see it's pretty
interesting. Is this used much? If we add it to the RFC, do you think we'd
want a separate function, or add another arg to transpose:
transpose([$a,$b], 0, @arr); # xchg
transpose([$a,$b], 1, @arr); # mv
How about (if perl6 allows passing arrays implicitly by reference
without arglist flattening)
transpose @arr, $a, $b; # xchg
transpose @arr, {$a = $b}; # mv
transpose @arr, [0,3,4,1,2]; # PDL reorder
Aliasing for bounded typed arrays is simple:
each array has a block of data (void *) and vectors of shape (int[]),
strides (int[]) and offset (int). To get element arr[i;j;k] Perl
accesses into the typecast block
((type *) data)[offset+i*stride[0]+j*stride[1]+k*stride[2]]
When creating an alias only the shape, strides and offset are
manipulated which tells the new alias how to interpret the same block of
data differently. This kind of implementation is used in PDL, NumPy and
GSL AFAIK.
In PDL we have found it useful to have a method turning the alias into a
being of its own ($pdl-sever, oops undocumented).
Christian
