"David L. Nicol" wrote:
> > =head1 TITLE
> >
> > Default methods for objects
>
> Title does not match description. How about
>
> Overloadable bracketing
>
> or
>
> Brackets as Methods
>
> or
>
> Syntax as Overloadable Methods
Good point! Will be part of v2.
Christian
Karl Glazebrook wrote:
>
> Just a test to see if this list is actually alive...
Seems to be. But no great activity yet. Where to start?
Christian
"David L. Nicol" wrote:
>
> Looks like if we give the data type control over what
> the meaning of square brackets after it is, the rest
> becomes example code. I think this s covered in the
> horribly misnamed http://dev.perl.org/rfc/115.pod which
> covers overloading bracketing.
Agreed. We sh
Dan Sugalski wrote:
> It looks like we need to be able to override operations on arrays, have
> multi-dimensional arrays, and do some rather odd slicing operations that
> give values still linked to the original matrices.
>
> Has anyone asked for complex number support yet?
It's hidden in one o
Dan Sugalski wrote:
> to make foo and bar 5x5x5 matricies that you casn multiply to get baz then,
> well, say it. If that means you need to define a way to provide overridden
> operators in the Matrix package, then go for it and say that.
>
> Let the -internals folks worry about the Weird Magic
Karl Glazebrook wrote:
> The key from my point of view is to have enough syntactical
> hooks in the core so that using it is not like wading through
> treacle. Hence the PDL RFCs - especially on [] overloading and ranges.
>
> The Numerical Python people seem to have accomplished this, and we can
Karl Glazebrook wrote:
> "->" really sucks as something to routinely type in to a interactive shell
> all the time. I hate it.
I can not agree more. It just seems terribly unnecessary.
Just allow us to directly overload some of the braces/parentheses for
objects.
I would be happy with
$pdl(0:
> I'm here because:
> * I think the PDL folks have valid needs
> * I think a lot of people are having trouble making suggestions for
>language changes that mesh well with other constructs in the
>language.
> * I'm not able to tell you want you need, but I will try to help
>you come
Bart Lateur wrote:
> Personally, I would like to have Larry's fiat *before* trying to iron
> out the incompatibilities. It could be that you throw away something
> that Larry would approve of, and keep something he doesn't like.
I'd vote to go for what we think is the best compromise. If Larry
i
"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
Tuomas Lukka wrote:
> > Do we really need PDL objects in perl 6? How about we investigate building
> > compact arrays into the language? We're already talking about how we can add
> > typing to the language--I would have thought that if these semantics make it
> > in, we could look to optimise ho
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 returns an untyped and unbounded LOL. In that
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.
>
> I've been watching this RFC for a
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 to touch on the question what
$#arra
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 I'd
want that I'd write
@t[|i;|
Doug Hunt wrote:
> You might also look at APL, a language which has been doing really funky
> N-dimensional
> array manipulation for longer than anyone...
I'd say PDL has probably been influenced quite strongly by APL/J in its
PDL threading notion. And with more and more "funny characters" makin
Nathan Wiger wrote:
> what people would want to use the ops for, and it's also more usable to
> us non-PDLers.
I'd like to suggest that it is not a very good idea to start dividing
the world into PDLers and non-PDLers. There are a multitude of reasons
but I am not keen to go into details.
Chr
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
>
Buddha Buck wrote:
> When I heard about transpose() (as well as reshape(), etc), I was
> concerned about the time it would take to execute these complex
> operations. To wit, naively, I believed that a lot of data shuffling
> would be necessary.
If I understand your message correctly this is ex
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. I'd say why not also allow the mv syntax? It is
syntactically different from the oth
Karl Glazebrook wrote:
> the arguments to reshape should be sizes not last elements (i.e. N's
> not N-1's).
Yup, it's simple: size (N) vs index range (0..N-1)
> How does this sound?
Logical and consistent ;)
Christian
Jeremy Howard wrote:
> (I'm not assuming the no-flattening thing, since that's another source of
> angst altogether!)
What is the no-flattening thing?
Christian
Ilya Zakharevich wrote:
>
> On Fri, Sep 22, 2000 at 05:24:55PM -0400, Karl Glazebrook wrote:
> > 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 heavy PDL
> > user.
>
> ...Do you say you are confused by using
23 matches
Mail list logo
