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 multiplication you propose is
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
[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. I'd say why not also allow the mv syntax
[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 post
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
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:
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
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
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...
PDL already allows $x = 3*$y
why
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
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
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 with a
Let's jump in. This RFC proposes a Creshape 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
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
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.
Why is it important for overloaded
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 out? RFC 204 simply specifies
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
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 reshape()
should be
the maximum index
Perl6 RFC Librarian (aka Damian Conway) wrote:
This RFC (seriously) proposes Perl 6 provide Cany and Call 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
Forwarded from perl6-meta
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
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 couple things that the NumPy one lacks that RFC 148
currently has
[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 I'd
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?
http://pdl.sourceforge.net/PDLdocs/Core.html#reshape
Removed perl6-announce x-post
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):
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 get stuck on the '*'
example, because
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 Cmerge and demerge do not make
- a copy of the elements of their arguments;
- they simply create an alias to them:
-
1 @a = (1,3,5);
2
[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.
I've been watching
Moved to perl6-language-data from PDL Porters
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 though...
as well as @start..gen:
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
could
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 clear
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
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 extension.
X-posted to [EMAIL PROTECTED]
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
33 matches
Mail list logo
