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:
.
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, in which the
behaviour of multiplication you propose
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 major
[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 array.
Jeremy:
you should look at the PDL mv() and xchg() methods
and factor this into your thinking!
Karl
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 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
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
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 work.
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.
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.
Do you have a better suggestion
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 floating point number
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
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
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
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
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 )
That is, you can
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
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
"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 scalar. So, $x[3] *is* a scalar.
That scalar could be a reference
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 to see how cutting out the
"line noise" would make
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 with.
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
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 used to believe that too! Honest
"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 hashlike
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 really what
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 reason
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
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 that there
Nathan Wiger wrote:
This is one of the things I really like about Perl: being able to tell
what type of thing I'm looking at. Is is a list? A single value? A hash
of values? No sweat, look at the prefix.
I appreciate the point. I discuss it in the RFC and why I think it
no longer works.
I
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 objects, why
nd @ really
required? There are too many objects types and not enough funny symbols..
even with Unicode.
Karl Glazebrook
Jeremy Howard wrote:
BTW, I'd like to see a more lightweight currying mechanism too. The
challenge is to find a 'perlish' but not heavyweight approach...
Ah, good.
One often wishes one could just write it as C/fortran style
loops and have the language figure out how to do the loops efficiently.
Anyway some integration of concepts for handling large numerical computation
into the core would definitely be a good thing.
Karl Glazebrook
34 matches
Mail list logo
