Uri Guttman wrote:
> > "BS" == Benjamin Stuhl <[EMAIL PROTECTED]> writes:
>
> >> Can anyone think of things I've forgotten? It's been a while since
> >> I've done numeric work.
>
> BS> ln, asinh, acosh, atanh2?
>
> dan mentioned log (base anything) but i don't recall ln. and definitely
>
Sam Tregar wrote:
> On Wed, 29 Aug 2001, Jeremy Howard wrote:
>
> > The answer used in .NET is to have a dispose() method (which is not a
> > special name--just an informal standard) that the class user calls
manually
> > to clean up resources. It's not an ideal solut
Hong Zhang wrote:
> Most of finalization is used to deal with external resource, such as open
> file, socket, window. You don't really want to depend on finalization,
> since it is very likely run out of default file descriptor limit before
> the finalization kicks in. The rule of thumb is to let
David L. Nicol <[EMAIL PROTECTED]> wrote:
> Yes, exactly. I would like to have a transpose operator, which
> will work on a list of hash refs, so this:
>
> $solids = [1..7];
> $stripes = [9..15];
> foreach (transpose($solids,$stripes));
> print "the $_->[0] ball is the same color as the $_->[1]\
"Sterin, Ilya" <[EMAIL PROTECTED]> wrote:
> Hmmm. Didn't think about that. That would be a nice way, that way you can
> manipulate it's behaviour depending with how many aliases you provide.
>
> for my $el1, $el2 ( (@foo, @bar) ) {
> print "$el\n"
> }
>
> $el1 and $el2 would of course be ali
"John Porter" wrote:
> Sterin, Ilya wrote:
> > Don't really know which would be more helpful, since I first need to
find a
> > scenerio where I would use this facility, then what result would I
expect
> > once the shortest list runs out.
>
> Let us ask the PDL folks.
>
> In fact, I'm quite sure th
"raptor" <[EMAIL PROTECTED]> wrote:
> but now I'm looking at these too...
> http://dev.perl.org/rfc/90.pod
> http://dev.perl.org/rfc/91.pod
> http://dev.perl.org/rfc/148.pod
>
> so may be what must be the order of passing the arguments and other stuff
> should be done via these proposed functions.
"raptor" <[EMAIL PROTECTED]> wrote:
<...>
> the idea of aliasing is to preserve the fast access and on the other side
to
> shorden the "accessor"(i.e the way to access the structure) and make code
> clearer.(mostly u can choose a name that has better meaning in your
context)
>
This reminds me... a
Michael Schwern wrote:
> mjd tricked me into reading his "Strong Typing Doesn't Have To Suck"
> talk, and now I'm looking at the typing proposals for Perl 6 and
> thinking... boy, its going to be almost as bad as C. That sucks.
>
> Is there hope? I dunno, but read the talk.
> http://perl.plover.
> What I was suggesting was to consider broadening what the
> $foo : bar style postfix sub syntax allows/assists bar to do,
> so that bars can be used to set properties OR do other stuff.
>
What's the practical utility of this? This discussion has been pretty
abstract so far... It's easy to see ho
Dan Sugalski wrote:
> At 09:40 PM 4/6/2001 +0100, Richard Proctor wrote:
> >On Fri 06 Apr, Dan Sugalski wrote:
> > > This is, I presume, in addition to any sort of inherent DWIMmery? I
don't
> > > see any reason that:
> > >
> > > @foo[1,2] = ;
> > >
> > > shouldn't read just two lines from tha
Michael G Schwern wrote:
> Hmmm... an object which contains a method reference which contains a
> referent to itself.
>
Yup. I don't know why some people think that circular references are complex
;-)
>
> > Something like this would be nice in a class that creates method
> > references--it would s
Michael G Schwern wrote:
> On Sun, Dec 17, 2000 at 12:11:01PM +1100, Jeremy Howard wrote:
> > Something to be careful of--it's easy to create a circular reference
when
> > using method pointers. As a result, neither the referrer nor referee
objects
> > are ever des
Michael G Schwern wrote:
> package Class::MethRef;
> use strict;
>
> sub meth_ref {
> my($proto, $method, @args) = @_;
> return sub { $proto->$method(@args) };
> }
>
>
> So this...
>
> my $meth_ref = $obj->meth_ref('foo', @some_stuff);
> $meth_ref->();
>
> is equivalent to this..
>
> $
Uri Guttman wrote:
> > "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
> DS> So unless we come up with something concrete, the goals are:
>
> DS> 1) A nebulous ~10% faster
> DS> 2) Faster in the things that annoy Dan the most
> DS> 3) Faster in the OO bits the folks upstairs from me u
Leon Brocard wrote:
> Bradley M. Kuhn sent the following bits through the ether:
>
> > It should be noted that in Larry's speech on Friday, he said that he
wanted
> > to write the Lexer and Parser for Perl in some subset of Perl. :)
>
> Is there a writeup somewhere for those who couldn't attend?
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
Nathan Wiger wrote:
> Jeremy Howard wrote:
> >
> > Can we have an isnull() function then, please. Otherwise there's no
> > operation to test for nullness.
> >
> > PS: Nullness? Nullility?
>
<...>
>use tristate;
>$a = undef;
>
> =head1 TITLE
>
> Add 'tristate' pragma to allow undef to take on NULL semantics
>
<...>
>
> The C pragma allows for undef to take on the RDBMS concept of
> C, in particular:
>
>1. Any math or string operation between a NULL and any other
> value results in NULL
>
Any math or string or
[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
Nathan Wiger wrote:
> Jeremy Howard wrote:
> >
> > Good question. I haven't tackled this in RFC 83, because it is a more
> > general question about attribute syntax. We don't really have a good
> > attribute syntax RFC yet, although Nate threw up some ideas
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
Greg Boug wrote:
> Apologies if these comments have already been noted...
>
> > my $PI : constant = 3.1415926;
> > my @FIB : constant = (1,1,2,3,5,8,13,21);
> > my %ENG_ERRORS : constant = (E_UNDEF=>'undefined',
E_FAILED=>'failed');
> >
> > Constants can be lexically or globally scoped (or a
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...
> >
>
Ed Mills wrote:
> These would be perlish, nice, terse, succint, and economical:
>
<...>
>
> ($i, $i, $k) += 2;
>
>@nums = 10 * @nums;
>
These are both covered by RFC 82.
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
Michael G Schwern wrote:
> On Mon, Sep 18, 2000 at 01:35:42AM -0400, Adam Turoff wrote:
> > Background: RFCs should be in development until frozen or retired.
> >
> > Problem: Frozen RFCs are being updated.
>
> Solution #4: Slip the RFC status back to 'developing'.
>
> If someone updates a frozen
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
> [EMAIL PROTECTED] wrote:
> >
> > Could we please take discussion of 179 to -data? I think that's where
> > it should be.
> >
> > K.
>
> Personnally, I don't see any objection to this.
> If everybody is ok, why not ?
>
> How should I process ? Submit again the proposal with a modified
> mailing-
Dan Sugalski wrote:
> ...would anyone object to the _binary_ operators being used
> instead? They don't have short-circuit semantics, and generally don't have
> any reasonable meanings for hashes and arrays. With that, instead of
> writing the above code, you'd write:
>
>@a = @b | @c;
>
> noth
Gregory S Hayes wrote:
> Types just seem so very un-perl. There is much to be said for the
> universal scalar vairable. I'm not sure I fully understand just why we
> NEED types in the language. We have functions such as:
>
> my $integervalue = int($value);
>
> and...
>
> my $float = sprintf("%2.2f
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
Jonas Liljegren wrote:
> Does any other RFC give the equivalent to an 'in' operator?
>
>
> I have a couple of times noticed that beginners in programming want to
> write if( $a eq ($b or $c or $d)){...} and expects it to mean
> if( $a eq $b or $a eq $c or $a eq $d ){...}.
>
> I think it's a natura
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
Nathan Wiger wrote:
> Tom Christiansen wrote:
> >
> > Ever consider then having
> >
> > ($a, $b, $c) = ;
> > or
> > @a[4,1,5] = ;
> >
> > only read three lines? I mean, how many if any builtins would it
> > make sense to make aware of this, and do something "different"?
>
> Personally, I
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
Tom Hughes wrote:
> > For example, in Perl you have for a long time been able to do this:
> >
> >($one, $two) = grep /$pat/, @data;
> >
> > However, what currently happens is grep goes to completion, then
> > discards possibly huge amounts of data just to return the first two
> > matches. For
Michael G Schwern wrote:
> If pop @array, -1 == shift @array, 1 and shift @array, -1 == pop
> @array, 1, and if both Ways To Do It are almost exactly the same, then
> there's no value to allowing negative numbers. In most cases I'd
> expect passing a negative number to be a mistake on the program
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
Gael Pegliasco wrote:
> > First is the choice of arrays verses hashes as the choice for set
storage.
> > Arrays are obviously easier to construct, but hashes are both faster
> > implementations, and easier to determine membership.
>
> Well in fact I'm interested by such functions in order to manip
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
1 - 100 of 142 matches
Mail list logo
