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
[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);
That would not be very pretty, indeed. It would
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
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 entirely miss the problem of cryptocontexts
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 =
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 right.
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
[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.
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
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 person.
: I don't know if Larry
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 dimensions of
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:
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 suggestions
"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-get_x, $r-get_y];
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
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 be
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 "[]"
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:
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...
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:
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
Dan Sugalski wrote:
On the other hand, just extending out arrays to be multidimensional may
well be good enough.
This is my view.
Karl
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
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
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 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 different
eh?
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
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 manipulation stuff. I think a happy medium would
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
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!
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
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
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
41 matches
Mail list logo
