I still feel this adds yet another layer of inconsistency and confusion.
I can't look at a piece of code and know what it does, without referring
up N lines to the top of the scripts.
How is the infinite loop problem any different from other Halting problems?
Karl
Christian Soeller wrote:
>
[several replies flattened into one]
On Monday, July 15, 2002, at 01:45 PM, Sean O'Rourke wrote:
> On Mon, 15 Jul 2002, Luke Palmer wrote:
>
>> On Mon, 15 Jul 2002, Karl Glazebrook wrote:
>>
>>> @solution = (^-@b + sqrt(@b^**2 ^+ 4^*@a^*@c) ) ^/ (2^*@a);
>
de like this I *WILL* give up on perl,
and resort to Numerical
Python or IDL instead.
appalled,
Karl Glazebrook
get rid of them all!!
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,
Ilya Zakharevich 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 not appropriate.
for example?
> I did not see any viable proposal on changing things in a majo
Ilya Zakharevich wrote:
>
> On Sat, Sep 23, 2000 at 11:32:58AM -0400, Karl Glazebrook wrote:
> > Yes this is the point. I guess another way of looking at it is
> > saying that 3*@a operates in a list context not a scalar context
>
> Well, this shows that you enti
It was also described in one of the PDL RFCs ages ago.
The general data structure was described which basically
allows a:b:c slices, transposes (read arbitrary dimension
swapping) etc with no copy overhead.
In PDL
$a = zeroes(5000,4000,3000);
$b = $a->slice('2:5000:2,3:3000,0:3000:10')->xchg(
Jeremy Howard wrote:
>
> 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
[EMAIL PROTECTED] wrote:
>
> Ilya Zakharevich wrote:
> > ...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
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!!
anything else would be WRONG
Ilya Zakharevich wrote:
>
> On Sat, Sep 23, 2000 at 10:41:07AM +1100, Jeremy Howard wrote:
> > 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 r
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 h
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 las
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
Jeremy:
you should look at the PDL mv() and xchg() methods
and factor this into your thinking!
Karl
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 step backwards?
KArl
Ilya Zakharevich wrote:
> As shipped: no. But if this is made a primitive (which I would not
> like), then the only change which is needed is to make the
> tie::multi::range() token to be followed by 3 numbers.
>
> [Aside: Why not make ternary-range operator into 10 :: 20 :: 2 ?]
That would wor
Hi Ilya,
I have three questions about your RFC:
Firstly does your proposal allow for a slice like 10..20:2 (i.e. with
a stride of 2) ?
If not is there an easy way to incorporate that?
Secondly, what about having multidim support in the core so that the
tie-tokenisers get optimised away? i.e.
Well in PDL we called them 'piddles' for precisely this reason!
The problem is they ARE arrays, which perl already has, just with a
more compact storage and nicer representation.
And we ARE proposing to make them look like plain perl arrays remember!
So let's keep CALLING them arrays!
I sugg
"David L. Nicol" wrote:
>
> Nathan Wiger wrote:
>
> > Well, this is not bad, only it's not without its problems. Say you
> > wanted to get your indices implicitly:
> >
> > @a[getindices()];
> > @a[$r->get_x, $r->get_y];
>
> @a["@{\(getindices())}"];
> @a[join $",$r->ge
I would rather see one largeish RFC integrating all these. More RFCs
are not necessarily better.
"Advanced Perl Multi-dimensional notation".
And n-dim things are not necessarily matrices.
Karl
Buddha Buck wrote:
>
> If I'm stepping on toes here, please tell me...
>
> Here are some suggestion
Buddha Buck wrote:
>
> At 08:10 AM 9/1/00 +1200, 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;;]
>
> Would you go for
Jeremy Howard wrote:
>
> The RFCs I envisage are:
>
> - Overview of matrix RFCs
> - Notation for declaring and creating matrices
> - Notation for declaring sparse matrices
> - Notation for indexing matrices with a LOL as an index
> - ';' for slicing matrices
> - @#mat for getting the dimen
Larry Wall wrote:
>
> Karl Glazebrook writes:
> : I have a lot of respect for Larry, but as a scientist I distrust all this
> : deference to one single authority.
>
> Well, sure, but someone still has to decide who gets the grants. :-)
But it's not always the same per
This is beginning to sound like something I would support.
Heavens are we approaching some sort of consensus.
This also addresses one pain in current PDL which is the
difficulty of multi-dim indexing.
Buddha Buck wrote:
>
> Here is a quick summary of the proposal:
>
> In the raw, arrays can b
Nathan Torkington wrote:
> I'm all for taking proposals on a particular subject (e.g., the PDL
> multidim matrix suggestions, or the lvalue subs suggestions) and
> giving the list a week to boil them down to one RFC that recommends an
> implementation and says what was rejected and why.
ok
> >
Jeremy Howard wrote:
>
> > 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
Jeremy Howard wrote:
My plan for this list is to strongly encourage RFC maintainers to work
> together to remove conflicts and incompatibilities from their RFCs. This
> will sometimes require retiring a number of RFCs and writing a new
> consolidated one.
>
> My hope is that we can have a single
Jeremy Howard 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. It needs to fit in with
> the rest of the language--our proposals won't get through if programs look
> quite different in sections just because ar
Jeremy Howard wrote:
> @b = (1,2,3);
> @c = (2,4,6);
> @d = (-2,-4,-6);
> $sum = reduce ^_+^_, @b * @c + @d;
>
> should be evaluated as if it read:
>
> $sum = 0;
> $sum += $b[$_] * $c[$_] + $d[_] for (0..$#a-1));
>
> That is, no temporary list is created, and only one loop is requi
Nathan Torkington wrote:
>
> Karl Glazebrook writes:
> > Yes. And for the record I also think the current approach of lets generate
> > ten million RFCs and Uncle Larry knows best is nuts. There are already
> > too many RFCs on this topic alone to grasp coherently.
&
A comment:
we are after SIMPLE syntax. This means like C, Fortran, IDL and Matlab.
Perl is about working like most people expect.
To access a single element we want
$a[$i,$j,$k]
for a slice we want
$a[10:20:2, 11:30:3]
Replace "," and ":" with your favourite punctuation stop, and "[]" with
Christian Soeller wrote:
> What Karl was trying to get at is a suggestion to have one RFC on
> indexing instead of three competing ones, for example. The current
> approach seems to be make a new RFC always (regardless what is there
> already). The other approach would be to take existing ones a
The PDL extension module already does all that.
The point IS to get more PDL like functionality into the core, hence
Budda's and others RFCs.
This is what perl6-language data is discussing.
Karl
Michael Maraist wrote:
> Hence C-like matrixes. But apply various matlab like functionality to
> If you do a plain
>
> my int @foo;
>
> it'll end up with a contiguous block of memory anyway. :compact seems to
> me more an attribute for sparse arrays than anything else.
>
Uhm do you mean a contiguous block of 4 byte integers or a countiguous
block of perl scalar structures? It is the f
Jeremy Howard wrote:
>
> Karl Glazebrook wrote:
> > Dan Sugalski wrote:
> > 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 multidimensional indexing syntax.
> Furthermore, i
Dan Sugalski wrote:
> >It would be bad to have multiple RFCs suggesting the same thing.
>
> Nope, it wouldn't be.
>
> Don't assume that any particular RFC will be accepted in its entirety
> either--it's always possible that Larry'll take the good bits and leave the
> rest...
>
>
Dan Sugalski wrote:
>
> At 12:28 PM 8/29/00 -0400, Karl Glazebrook wrote:
>
> >But scalars are not compact.
>
> Since scalars are singular things, how would you compact them anyway?
>
If I say $a = ones(float,10,10) in PDL then each element of $a
is a 4 byte floatin
Dan Sugalski wrote:
> On the other hand, just extending out arrays to be multidimensional may
> well be good enough.
>
This is my view.
Karl
You should have a look at the PDL RFC 117 before submitting this.
It would be bad to have multiple RFCs suggesting the same thing.
Much better to come to some agreement HERE on what the syntax
should be first, then submit consensus RFCs.
My view: I am pretty flexible I like most suggestions as
Yes that is a good point, which I had forgotten about in my
concern over syntax.
Some guidance is needed about what the default passing is likely
to be in perl6.
Will
(@x,@y) = mysub @a, @b
implicitly pass by reference?
Karl
Christian Soeller wrote:
> In summary, I doubt that having PDLs b
But scalars are not compact.
Nathan Wiger wrote:
> To avoid anyone getting yelled at by TomC or someone else: Yes. Anything
> individual in Perl is a scalar. By definition. Please don't try to
> change this.
>
> For more details on this, please read this email:
>
> http://www.mail-archive.co
My apologies for being too succinct. "lost" is a bit of an emotive word
which is somewhat inaccuracte.
I still believe in RFC 109 and I think I made a good case based on my
own reasons. However the overwhelming majority of responses were negative,
for their own very good albeit different reasons
Consider
@x[10:20, 20:40:2, 30:50]
This ALMOST works in the current Perl. @x gives array context,
then the , produces a list.
If [] is overloaded on @a then the subroutine sees a list like
"10:20", "20:40:2", "30:50"
The only reason it does NOT work in the current perl is that "10:20"
is a s
Using semicolons is an interesting idea. But consider:
@a[10:20; 30:40];
The ":"s and ";" are awfully hard to visually distinguish.
c.f.
@a[10:20, 30:40];
What do people feel about the whole replacing ".." by ":"
issue?
Karl
Nathan Torkington wrote:
>
> Karl Glazebrook writes:
> > I agree with your sentiments. Most people in PDL DO come from the
> > number crunching/scientific background.
>
> Whereas the rest of Perl users don't, and will probably never need the
> matrix manipulatio
Nathan Torkington wrote:
> > (1) The current
> >
> >$pdl->slice("0:$n,(0)");
> >
> > syntax sucks.
>
> Would:
>
> $pdl->[0:$n][0][:]
>
> suffice? I figure this would translate into something like:
>
> $pdl->subscript( 0, $n )
> ->subscript( 0 )
> ->subscript( undef, undef
Hi Baris,
I agree with your sentiments. Most people in PDL DO come from the
number crunching/scientific background.
I would say that a matrix is just a special case of a general
N-dimensional compact array which obeys various rules. PDL
supplies a matrix-mult operator ("x") and other matrix ops
Nathan Wiger wrote:
>
> > OK here is a basic question: how do we specify element access in
> > PDL type arrays?
> >
> > $a[$i][$j][$k] or $a[$i,$j,$k]
>
> Both of these already have firm meaning in Perl. The second one is used
> to bite off selected elements of an array. So if you want a differe
Ssshh don't mention RFC 109!
To give some background:
RFC 109 comes from me, and caused some "interesting" debate on
perl6-language. It's not that relevant to PDL.
RFC 115-117 are key RFCs from the PDL-Porters - things we really
want to see to make Perl better for numerics. These are the
main
There is already a reshape() in PDL.
Obviously that only applies to PDL arrays.
But if PDL style arrays get in to the core, then that sort of
functionality ought to arise.
OK here is a basic question: how do we specify element access in
PDL type arrays?
$a[$i][$j][$k] or $a[$i,$j,$k]
Most nu
Christian can you repost them here then?
Karl
Buddha Buck wrote:
> I'm here... I thought the formation of perl6-language-data was to discuss
> the PDL RFCs anyway...
>
> >Karl
Well the PDL RFCs seem to have been totally ignored on perl6-language.
Maybe we should discuss them here, come to some conclusions and
present them with a fait accompli. "These are the recommendations
of perl6-data".
Who is here anyway?
Karl
Just a test to see if this list is actually alive...
Karl
Numerical python uses "..." in the same sense for axis
lists in multi-dim arrays. (Improved syntax for multidim
arrays is one wishlist item from PDL for the perl core.
See RFC117)
NumPy allows you to say:
a[..., :];
where "..." means "however many", - so this is a slice along
the last dimen
Ariel Scolnicov wrote:
>
> Karl Glazebrook <[EMAIL PROTECTED]> writes:
>
> [...]
>
> > o Why do I think perl has too much line noise? Because of code like this:
> >
> > @{$x->{$$fred{Blah}}}[1..3]
>
> This is indeed horrible. However, I fail
"Myers, Dirk" wrote:
>
> Karl Glazebrook wrote:
>
> > But what is $x[3] ?
>
> > It could be a scalar.
>
> > BUT it could be a reference to a list.
>
> > It could be a reference to a 2D PDL image.
>
> ... but references are sca
To go through a few points that has arisen:
o Why do I think "@" is useless?
OK clearly @x is a list. Good old perl4.
But what is $x[3] ?
It could be a scalar.
BUT it could be a reference to a list.
It could be a reference to a 2D PDL image.
etc.
so clearly we have no real i
Well said!
Nathan Torkington wrote:
>
> Dan Sugalski writes:
> > Unfortunately, I think you're somewhat under-informed as to the inherent
> > capabilities of people's brains.
>
> Ok, at this point I think all parties have to step away and let the
> RFCs fall where they will.
>
> It's obvious
Jon Ericson wrote:
> I've spent almost a day trying to come up with a polite response to this
> suggestion. I have started this mail 3 or 4 times but deleted what I
> wrote because it was too sarcastic, angry or dismissive. This RFC
Thanks!
> strikes to the very heart of Perl as far as I'm c
Well said!
My take: I like perl, I don't mind it the way it is. But I'd be happier if
it was a lot more like python! (indentation aside)
I guess the question arises - how radical is perl6 allowed to be?
Karl
Kai Henningsen wrote:
> And context dependency is bad for people.
>
> There is a reas
Damien Neil wrote:
> What makes you presume this? Perhaps snrub() is something like this:
>
> sub snrub {
> foreach (@_) {
> frobnicate $_;
> }
> }
>
> You appear to arguing that expressions in function argument lists should
> not be evaluated in a list context. Is this real
"J. David Blackstone" wrote:
>
> > =head1 TITLE
> >
> > Less line noise - let's get rid of @%
>
> I understand that with the pervasiveness of object-orientation we
> are now more than ever seeing objects that behave like arrays and
> hashes and that it seems strange to see these listlike or ha
Damien Neil wrote:
>
> On Tue, Aug 15, 2000 at 05:45:04PM -0400, Karl Glazebrook wrote:
> > I hope people will actually read the RFC before coming back with these
> > canned responses which I (and presumably everyone else on this list)
> > am completely familiar with. I
Nathan Torkington wrote:
> * you misunderstand the purpose of $ and @, which is to indicate
>singular vs plural. You say a $ indicates a string or number,
>but really it indicates a single thing. Similarly @ isn't just
>a variable marker, it's used to indicate that you get multiple
Nathan Wiger wrote:
> Ok, here goes. First off, I *did* read the RFC. I never respond before
Thanks, this response is more like it.
> reading. Personally, I wish people would quit coming up with these silly
> "let's drop the prefixes" RFC's that everyone on this list is completely
> familiar wit
Jon Ericson wrote:
>
> Perl6 RFC Librarian wrote:
>
> [snip reconstructionist history and newer-is-better fallacy]
>
> > I argue in this Brave New World the distinction between C<$x>, C<@x> and
> > C<%x> are no longer useful and should be abolished. We might want
> > to use all kinds of array o
67 matches
Mail list logo
