Just a test to see if this list is actually alive...
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
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
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
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
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
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 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
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
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 s
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
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
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
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 floatin
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...
>
>
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
> 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
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
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
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
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.
&
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
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:
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 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
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
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
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 suggestion
"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
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
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.
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
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
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 las
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
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
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
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
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(
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
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
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,
48 matches
Mail list logo
