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
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
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
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 vectors
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
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
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
$#array
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.
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 while. I
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't
11 matches
Mail list logo
