Ilya Zakharevich wrote:
> On Sun, Oct 01, 2000 at 08:51:04AM +1100, Jeremy Howard wrote:
> > Please no! Anything that makes it harder to write 'quick-and-dirty'
scripts
> > is never going to fly--this is part of what makes Perl special.
>
> Why? I see no problem i
Karl Glazebrook wrote:
> Ilya Zakharevich wrote:
> > On Thu, Sep 28, 2000 at 11:39:51AM -0400, Karl Glazebrook wrote:
> > > > > so what is wrong with the statement '@y = 3*@x;' then ?
> > > >
> > > > That other constructs *also* create an array context, in which the
> > > > behaviour of multiplica
In 2 and a bit days all RFCs must be frozen--those not frozen will be
auto-retracted by the librarian! So, could you please freeze your RFCs--the
following have some still outstanding:
Ilya Zakharevich <[EMAIL PROTECTED]> 8
David Nicol <[EMAIL PROTECTED]> 2
Buddha Buck <[EMAIL PROTECTED]> 1
pdl-p
Buddha Buck wrote:
> The main problem I see are these:
>
> @array = ([1,2],[3,4]); # 2-dimensional array, using LOL syntax
> print $array[[1,1]]; # prints 4, OK
> print $array[1]; # prints ?
> print $array[[1,1,1]]; # prints ?
> print $array[[1]]; # prints ?
>
> Ac
[EMAIL PROTECTED] wrote:
> Jeremy Howard wrote:
>
> > So where is mv(), you ask? If you use the 'reorder' syntax, but don't
> > specify all of the dimensions in the list ref, then the remaining
dimensions
> > are added in order:
>
> That sounds good.
Karl Glazebrook:
> Well if a dimension has N elements then the numbering of the elements
> runs 0...N-1
>
> similarly if the shape has M dimensions, then the numbering of the
> dimensions is 0..M-1
>
> the arguments to reshape should be sizes not last elements (i.e. N's
> not N-1's).
>
> I think t
Karl Glazebrook wrote:
> Jeremy Howard wrote:
> >
> > BTW, I notice that you're using dimension numbering starting at 0 for
your
> > transpose() examples. Is everyone happy to start at 0 rather than 1?
>
> OF COURSE!
[EMAIL PROTECTED] wrote:
> 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
>
You know, I had just logged in to pos
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 not
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 arr
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?
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 dif
Karl Glazebrook wrote:
> Ilya Zakharevich wrote:
> > f(3*@a)
> >
> > would typically be a list context - and suddently instead of 3*(1+$#a)
> > you get C.
>
> This is true, what I would propose is we declare 3*(1+$#a) outmoded and
> always have it mean C in all contexts.
>
> This of course wi
Bart Lateur wrote:
> Hmm... the problem is, I think, that array references and ordinary
> scalars are both scalars.
>
That's true, but they're scalars with different interfaces. In particular,
an array ref can be dereferenced and provides an array in doing so. If an
index can do this, then it's a
Christian Soeller wrote:
> Karl Glazebrook wrote:
> > Buddha Buck wrote:
> > > >
> > > > @x = 3 * $y[|i];
> > > >
> > > >It's not as clean as @x = 3 * @y, but it is cleaner context-wise.
> > >
> > > And one could argue that:
> > >
> > > @x = map 3*^_, @y;
> > >
> > > is cleaner yet...
> >
>
Bart Lateur wrote:
> On 20 Sep 2000 04:07:27 -, Perl6 RFC Librarian wrote:
>
> >Where an array is declared without ':bounds', @# returns the largest
> >bounds of each dimension that has been accessed:
>
> Wouldn't that be slow?
>
It depends. The array creation RFC proposes that LOLs declared w
Buddha Buck wrote:
> On RFC 204 (LOL refs as indices), I have followed the discussion from
> Ilya that list references will have problems when objects that used
> blessed references to lists as their internal representation are used
> as indices. This does indeed seem to be a problem, but I'm unc
> Let's jump in. This RFC proposes a C builtin with the following
> syntax:
>
Err... this syntax isn't what I expected at all! I thought the first
argument would define the shape of the result, like NumPy or PDL...
> When one array is passed in, it is split up. Here, the C<$x> and C<$y>
> determi
We need to get our -data RFCs wrapped up. Nate said it rather well
on -objects, so rather than rewrite what he said, I'll just repeat it here.
I had planned to get RFCs frozen by this Wednesday, but that's looking
overly optimistic, so let's aim to meet the same deadlines that -objects are
working
Ilya Zakharevich wrote:
> On Sat, Sep 16, 2000 at 07:15:34PM +1100, Jeremy Howard wrote:
> > Why is it important for overloaded objects to be used as array indices?
>
> Overloaded objects should behave the same way as non-objects.
>
> > Why
> > does RFC 204 rule that
Ilya Zakharevich wrote:
> On Sat, Sep 16, 2000 at 11:08:18AM +1100, Jeremy Howard wrote:
> > - How does it relate to RFC 204? Is it an alternative, or an addition?
>
> 204 cannot be implemented since it prohibits usage of overloaded
> objects as array indices.
>
Wh
> =head1 TITLE
>
> Data: Multi-dimensional arrays/hashes and slices
<...>
> =item *
>
> proposes a convenient syntax to slice multi-dimensional arrays;
>
> =item *
>
> proposes a convenient syntax create subobjects which behave as slices;
>
> =item *
>
> does it with as little overhead as possib
Adam Turoff wrote:
> I didn't use Date::Parse, but I did look for all RFCs still stting
> at v1 status. Since they're numbered chronologically, I cut off the
> bottom (anything submitted after 9/7).
>
> There are 100 RFCs in the list that follows. Code and data upon request.
>
Thanks Ziggy--very
Perl6 RFC Librarian (aka Damian Conway) wrote:
> This RFC (seriously) proposes Perl 6 provide C and C operators,
> and, thereby, conjunctive and disjunctive superpositional types.
>
Great to see this RFC'd--this will makes lots of data crunching code _way_
easier.
Now, I haven't quite finished re
Nathan Wiger wrote:
> Jeremy Howard wrote:
> >
> > RFC 203 defines a :bounds attribute that defines the maximum index of
each
> > dimension of an array. RFC 206 provides the syntax @#array which returns
> > these maximum indexes. For consistancy, the arguments to
> > rather use a transpose() function for this that can transpose across a
given
> > axis.
>
> You'll be RFC'ing that, I suppose? ;-) (But seriously, it sounds like a
> good idea)
>
Yes, I will.
> > I don't think we need to define the ability to work on multiple lists as
> > special behaviour. Pe
Nathan Wiger wrote:
> Jeremy Howard wrote:
> >
> > 148: Change to Numeric Python semantics of reshape(), or write
counter-RFC
> > specifying these semantics (preferably renaming this RFC's 'reshape' to
> > something else)
>
> There are a cou
Nathan Torkington wrote:
> Larry's going to release a draft of his langauge decisions on the 1st
> of October.
>
> My plan to prevent a flood of 100 new RFCs on September 30:
>
> - deadline for new RFCs of Sep 25. After that, only discussion of
>old ones.
>
> - send mail to existing autho
Christian Soeller wrote:
> Maybe that's already implicit in the broadcasting proposal but it
> wouldn't hurt to spell it out:
>
> A dimension size of 1 should be broadcasted to match that of the
> other operand. So, for example, the following shapes (returned by
> @#array) are compatible:
>
Christian Soeller wrote:
> Jeremy Howard wrote:
> >
> >
> >
> > > Wouldn't it be very useful if all of the applicable polymorphic
methods
> > > of RFC 159 would be overloadable for nD arrays (arrays becoming
> > > effectively instan
> Wouldn't it be very useful if all of the applicable polymorphic methods
> of RFC 159 would be overloadable for nD arrays (arrays becoming
> effectively instances of array objects)? I am not sure if this has been
> discussed before but I could think of a whole lot of applications. Often
> you m
Buddha Buck wrote:
> > Reading through the examples left me wondering about some
> > technicalities:
> >
> > > @t[|i;|j] = @a[|j;|i]; # transpose 2-d @a
> >
> > Written like this it would require that @a is exact 2-dim, i.e. it would
> > not just swap the first two dims of any n-dim array? I su
Buddha Buck wrote:
> At 12:00 AM 9/12/00 +1100, Jeremy Howard wrote:
> >[EMAIL PROTECTED] wrote:
> >> Reading through the examples left me wondering about some
> >> technicalities:
> >>
> >> > @t[|i;|j] = @a[|j;|i]; # transpose 2-d @a
>
Christian Soeller wrote:
> Jeremy Howard wrote:
>
> > However I like the Numeric Python reshape() semantics better:
> >
> > http://starship.python.net/~da/numtut/array.html
>
> Is that in any significant way different from PDL's reshape?
>
> htt
[EMAIL PROTECTED] wrote:
> Reading through the examples left me wondering about some
> technicalities:
>
> > @t[|i;|j] = @a[|j;|i]; # transpose 2-d @a
>
> Written like this it would require that @a is exact 2-dim, i.e. it would
> not just swap the first two dims of any n-dim array? I suppose if
Chaim Frenkel wrote:
> > "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
>
> DC> I *still* think it should be "unmerge"! ;-)
>
> Hrmpf. It should be reshape.
>
> (Which would be its own inverse and saves a keyword.)
>
reshape() has already been proposed (RFC 148):
http://dev.perl.org/rf
Doug Hunt wrote:
> Jeremy Howard wrote:
>
> > - Mathematica (combines functional, declarative, and procedural styles;
> > implements memoization, lazy lists, and array notation)
> > - Matlab (fast and simple array language)
> > - C++ expression templates such
Nathan Torkington wrote:
> Jeremy Howard writes:
> > No, there's no arbitrary decision. *Every* operator is component wise on
> > lists. It is internally consistent, and consistent with most other
languages
> > that provide array/list operators. It's easy to g
Nathan Wiger wrote:
> My main fear is that while this RFC seems really good for math ops, but
> seems too array- and PDL-specific. Here are some examples of mixed
> contexts; how would these be handled under the RFC?
>
> @user_data = @empty || $user;
> %files = scalar(get_files()) || @DEFA
Nathan Wiger wrote:
> The only thing that *really* makes me nervous about the RFC is this
> part:
>
> > > @d = @b * @c; # Returns (2,8,18)
> > >
> > > If the lists are not of equal length, an error is raised.
>
> I really don't like the "error is raised" part, at least not by default.
> Maybe
[EMAIL PROTECTED] wrote:
> Perl6 RFC Librarian wrote:
>
> > This RFC proposes using @#array, analogous to $#array, to get the list
of
> > upper bounds for a multidimensional array @array. The length of @#array
> > would indicate the dimensionality of @array.
>
> That's fine. This RFC does not seem
[EMAIL PROTECTED] wrote:
> Perl6 RFC Librarian wrote:
>
> > The bounds of an array or list can be specified at run time, of course:
> >
> > my int @t1 :bounds(@dimList) = getFromSomeplace();
>
> Hm, I think some clarification would be good. I'd imagine three cases:
> (1) getFromSomeplace retur
[EMAIL PROTECTED]
> Nathan Wiger wrote:
> >
> > > This RFC proposes that operators in a list context should be applied
> > > element-wise to the elements of their arguments:
> > >
> > > @d = @b * @c; # Returns (2,8,18)
> > >
> > > If the lists are not of equal length, an error is raised.
> >
>
Matthew Wickline wrote:
> (not on list, just tossing this in for discussion)
>
OK--we'll keep you cc'd in on this discussion.
>
> RFC 90 (v3) wrote:
> -> Both C and do not make
> -> a copy of the elements of their arguments;
> -> they simply create an alias to them:
> ->
> 1> @a = (1,3,5);
> 2
David L. Nicol wrote:
> > In order to work with lists of arbitary size, it is often necessary to
> > split a list into equal sized sub-lists. A C function is proposed
> > that achieves this:
>
> Are the sublists copies or aliases? I imagine they are aliases,
> but this could be specified in the
Robin Williams wrote:
> "Jeremy Howard" writes:-
>
> > The first version of this
> > RFC had a
> >
> > @start..$end:&gen
> >
> > but it just seems too dangerous, so I removed it. I'm still willing to
be
> > convinced thoug
[EMAIL PROTECTED] wrote:
> Jeremy Howard wrote:
>
> >
> > C<;> is particularly useful for creating slices of multidimensional
arrays:
> >
> > my int @array = ([1,2,3],
> >[4,5,6],
> >[7,8,9]);
> &
the web at
http://dev.perl.org/rfc/
=head1 TITLE
Overview of multidimensional array RFCs ( through )
=head1 VERSION
Maintainer: Jeremy Howard <[EMAIL PROTECTED]>
Created: 3 September 2000
Status: Developing
Last modified: 3 September 2000
Version: 1
Mailing List: [EMAIL PROTECT
Karl Glazebrook wrote:
> I would rather see one largeish RFC integrating all these. More RFCs
> are not necessarily better.
>
The -language WG chair has requested that each RFC contain just one key
proposal, and that multiple related RFCs be drawn together with an overview
RFC.
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 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
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
>
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
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
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
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
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
Buddha Buck wrote:
> I think that once you have LOL's automagically padded to size, and that
> size stored as an intrinsic part of the LOL, you no longer have a
> traditional LOL. You have something that looks, walks, and quacks like
> a matrix and doesn't walk or quack like an LOL. Why not call
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
>
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 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
Dan Sugalski wrote:
> At 02:16 PM 8/30/00 -0400, Karl Glazebrook wrote:
> >subgroups should iron out there differences among themselves and come up
> >with a coherent set of proposals.
> >
> >the final decision should not be in the hands of one person.
>
> Someone ultimately has to make the in or
Buddha Buck wrote:
> RFC 169 says it would be nice if:
>
>@a[^i;^j] = @b[^j;^i];
>
> did a transpose operation.
>
> Should the syntax also allow:
>
># fill a 10x10 array with 0-99
>my @table: bounds(10,10);
>@table[^i;^j] = ^i*10 + ^j;
>
I think it should--it seems a natural e
Karl Glazebrook wrote:
> There is a difference between a List of Lists and a multi-dimensional
array - the
> latter is rectangular, e.g. the rows are all the same size so you don't
have to
> store the sizes of individual ones. So the latter needs much less storage
overhead.
> How would you be prop
> 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
This post attempts to consolidate and summarise my proposals which I hope
provides a platform for n-dim matrices/tensors. I have repeated parts of
earlier posts to avoid confusion--sorry for the redundancy. I've also fixed
some areas from earlier posts--hopefully the examples here are correct and
Dan Sugalski wrote:
> On Wed, 30 Aug 2000, Jeremy Howard wrote:
> > Furthermore, if it has a single basic data type and is declared
':compact'
> > it should be stored in a contiguous block of memory.
>
> If you do a plain
>
> my int @foo;
>
> it&
Nathan Wiger wrote:
> And I'm assuming this only returns one element, right? Because if it
> returns a list it's not a $scalar. I think by this:
>
>$a[[$i,$j,$k], [$x,$y,$z]];
>
> You might actually mean this:
>
>@a[[$i,$j,$k], [$x,$y,$z]];
>
Yes, that's what I meant--sorry for the con
This RFC is a good start. Here's some thoughts on ways to decrease the
amount of new syntax and avoid the HOF ambiguity... Also, I suggest multiple
RFCs for the different ideas contained within.
Buddha Buck wrote:
> I propose the use of ';' as a separator for index terms when accessing
> multi-di
Christian Soeller wrote:
> Jeremy Howard wrote:
> > >
> > Ditto. As I said yesterday, my current preferred option is that a list
ref
> > of list refs will also support a multidimensional indexing syntax.
> > Furthermore, if it has a single basic data type and is dec
Karl Glazebrook wrote:
> Dan Sugalski wrote:
>
> > On the other hand, just extending out arrays to be multidimensional may
> > well be good enough.
> >
>
> This is my view.
>
Ditto. As I said yesterday, my current preferred option is that a list ref
of list refs will also support a multidimensiona
Christian Soeller wrote:
> Chaim Frenkel wrote:
>
> >
> > The current thinking in -internals is that list flattening will be
delayed
> > to as late as possible.
> >
> > One possiblity would be that only @_ would do any flattening. It would
> > walk each argument with an appropriate iterator to ret
Chaim Frenkel wrote:
> Aren't RFC 90 (zip/unzip) and RFC 148 (reshape) really the same?
>
Yes. RFC 148 can also partition (RFC 91). I've updated RFC 91 to also allow
a 3rd argument that gives a step size--I haven't checked whether reshape()
can do this. The updated RFCs 90 and 91 don't seem to hav
Christian Soeller wrote:
> Jeremy Howard wrote:
>
> > Basically, I want to be able to create a list ref of list refs, specify
a
> > data type (eg 'int') and attributes of ':compact' or ':sparse', and have
the
>
> As Dan Sugalski suggested i
Buddha Buck wrote:
> > I think the better way is to take Buddha's idea (soon to be RFC'ed, by
> > the sounds of it), and make current arrays a little more flexible. It
> > sounds like we'll just have to add an extra dimension somehow, and then
> > "arrays of compact arrays" will simply be "arrays
First of all, apologies for my lack of input over the last
week--unfortunately I went on holidays pretty much as this list went online,
so I've been pretty quiet. Anyhow, for those who don't know me, I'm the
chair of perl6-language-data. For the remainder of its existance I'll be
more active.
Thi
David L. Nicol wrote:
> If arrays as we know them implement by using a key space restricted to
> integers, I think a reasonable way to get matrices would be to open
> up their key space to lists of integers.
>
I've been thinking along exactly the same lines. There's a lot of language
issues to c
79 matches
Mail list logo
