Re: hyper operators - appalling proposal

Trey Harris wrote: > Yes. This is my fear of hyperoperation being the default for normal > aggregates. Loops--and large, multiply-nested, potentially-infinite > ones--can spring out of code that doesn't look loopy at all. Erm... you > know what I mean. :-) > > Karl, do you have any objection

Re: RFC 231 (v1) Data: Multi-dimensional arrays/hashes andslices

Karl Glazebrook wrote: > > 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 back

Re: RFC 231 (v1) Data: Multi-dimensional arrays/hashes and slices

> Finally as an overload expert what do you think about the proposals > to make arrays overloadable objects so one can say things like: > > @x = 3 * @y; Is this where RFC 231's suggestion for OO slicing comes in (see quote)? > For example, > >$matrix1->[2..5; 2..4] * $matrix2->[1,3,

Re: RFC 225 (v1) Data: Superpositions

Damian Conway wrote: > You can't, in serial implementation. But on a parallel architecture > or, better still, on a quantum device, you can run all the computations > in parallel. I see that. PDL has that as an experimental feature on any ufunc (in fact on any function that has a signature). It

Re: RFC 225 (v1) Data: Superpositions

Jeremy Howard wrote: > Do any() and all() have some magic around how they are implemented in von > Neumann computers that make them faster than standard CS searching > techniques? I'm probably naive here but shortcuts in a non-parallelized (classical) implementation rely on the usual shortcircui

Re: reshape() (was Re: Fw: Wrapup time)

Jeremy Howard wrote: > the maximum index of each dimension. A maximum index of '0' would mean that > that dimension is 1 element wide. Therefore '0' can not be special in > reshape(). Therefore we should use '-1'. -1 is the maximum index for any size in the usual fashion of perl array indexing.

Re: RFC 81 and broadcasting

Jeremy Howard wrote: > To be honest, I don't really get the point of stuff like NumPy's "NewAxis", > so I might be misunderstanding your proposal. But at least for your It's just another way to specify how implicit loops of a scalar operation are iterated over array elements (TIMTWTDI). Very mu

RFC 81 and broadcasting

ual/Pseudo-Index.html [2] http://numpy.sourceforge.net/numdoc/HTML/numdoc.html#pgfId-36371 -- Christian Soeller[EMAIL PROTECTED] x2770 Dept. of Physiology U. Auckland School of Medicine Auckland New Zealand

Re: logical ops on arrays and hashes

Jeremy Howard wrote: > > > > > Wouldn't it be very useful if all of the applicable polymorphic methods > > of RFC 159 would be overloadable for nD arrays (arrays becoming > > effectively instances of array objects)? I am not sure if this has been > > discussed before but I could think of a whol

Re: logical ops on arrays and hashes

Jeremy Howard wrote: > > > Of course they have reasonable meanings for arrays--element-wise operations > (RFC 82): > > http://tmtowtdi.perl.org/rfc/82.html > > Any operation you can do on a scalar you should be able to do element-wise > on a list, and certainly it's not hard to come up with si

Re: RFC 90 (v3) Arrays: Builtins: merge() and demerge()

Jeremy Howard wrote: > However I like the Numeric Python reshape() semantics better: > > http://starship.python.net/~da/numtut/array.html Is that in any significant way different from PDL's reshape? http://pdl.sourceforge.net/PDLdocs/Core.html#reshape > PS: How does one pronounce 'hrmpf'?

Re: $a in @b

> Quantum::Superpositions provides this in a more flexible way by adding the > 'any' and 'all' keywords. > > Superpositions.pm> > > One of Damian Conway's many promised RFCs will cover in

Re: n-dim matrices

Buddha Buck wrote: > Tensor or Matrix > Multidimensional list > what should we call it? > > I'd vote for matrix myself. It's short and sweet Fine ;) Just have a section in the elusive overview RFC that defines what we mean by matrix, e.g. not only 2D objects of linear algebra. With all the

Re: n-dim matrices

Jeremy Howard wrote: > I'd rather see the ';' be required, but the '(0..)' not be required, so you This is not good! There are a lot of routines where it is very useful to specify a slice as @a[0] that should work regardless how many dimensions @a really has. There are many instances in PDL

Re: n-dim matrices

Buddha Buck wrote: > Would you go for: > > @a[$first;*]; > @a[*;$last]; > @a[$first;*;$last]? > > Say yes, and I'll add it tonight! Nice! I'd go as far as implying a trailing ';*' if omitted. > > I'm unsure if @a[*;$middle;*] has any reasonable interpretation. Probably just croak. Unless so

Re: Upcoming RFC's...

Buddha Buck wrote: > RFC X+2: Retrieving Matrix dimensions > Present @#matrix as analogous to $#array > Discuss what $#matrix should return, as well as @#array > What is @matrix in scaler context? (undef, anyone?) Number of elements? For sparse matrices number of non-zero elements?

Re: n-dim matrices

Karl Glazebrook wrote: > This also addresses one pain in current PDL which is the > difficulty of multi-dim indexing. I like it, too ;) > > print $a[[0,0,0]];# literal ref list > > print $a[0;0;0]; # literal singleton ; list > > print $a[[$y,$y,$y]]; # variable-based ref list > > print

Re: Looping in perl

Baris wrote: > PDL has PP, which is very nice, but you still need to compile the code (Is > this correct? Is there any documentation about how to compile pp code?). There is. It's towards the end of the PP manpage. > sub sumit{ >my @a = @_; > $tmp = 0; >

Re: Designing Perl 6 data crunching (was Re: n-dim matrices)

Jeremy Howard wrote: > The 1st implementation of Perl 6 may not provide all the optimisations we've > come to expect from our data crunching language of choice. For this reason > maybe PDL will continue to exist independently in Perl 6 at least for a > while, although a fair bit of rewriting will

Re: Designing Perl 6 data crunching (was Re: n-dim matrices)

Jeremy Howard wrote: > > Baris wrote: > > First of all I know that perl syntax has limitations and I understand why > > the reasons of the new syntax proposals. And I think the syntax proposals > > are pretty good if you accept the syntax limitations. I don't think any of > > them do consider tha

Re: n-dim matrices

Jeremy Howard wrote: > 14,17;...20,29). What if we created a new operator ';' that works within a > list that creates a cartesian product?: > > (10:20:2; 11:30:3); # Cartesian product of 10:20:2 and 11:30:3 as a LOL A possible approach. Two issues: (1) others might argue that we should use

Re: n-dim matrices

Jeremy Howard wrote: > Sorry--I need to correct this. The correct syntax for a list slice under my > proposal would actually be: > > @a[10:20:2][11:30:3] > > It needs the '@' of course since it's returning an array, and it needs to > use the standard LOL notation with the extension to multipl

a strategy?

I have been thinking about what has come up on this list so far and was wondering if there isn't a strategy so that we all benefit and come up with a number of very strong proposals. The following seems to be a constructive approach to me: 1) There is nothing wrong with having many RFCs What rem

Re: New variable type: matrix

Jeremy Howard wrote: > > > 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, if it has a single basic data type and is declared ':compact' > it should be stored in a contiguous block of mem

Re: Access to the perl6 parser

Damian Conway wrote: > >> Regardless, you can already do this in perl 5, and will undoubtedly >> be able to do it in perl 6, with source filters. (If Damian can >> write perl that looks like Latin or Klingon, then python ought to >> be simple... :) > > I have a module (Language::

Re: New variable type: matrix

Baris wrote: > My motivation was to give more freedom to the developers of pdl so that > they can freely create the syntax without worrying about the workarounds. > Matlab, in my opinion, is much more natural to code than current pdl. It'd be interesting to hear what you dislike in particular.

Re: Access to the perl6 parser

Dan Sugalski wrote: > > Because source filters are: > > 1) Relatively new (5.005 IIRC, but I could be mis-remembering) > 2) A bloody pain in the neck to write > > Lots of things could use 'em if they were easier to do. That's one of the > goals of perl 6, I think. > Are there any docs in per

Re: Special syntax for 2-d

Baris Sumengen wrote: > > Hello, > > On 8/29/00 at 2:31 PM Jeremy Howard wrote: > > >The role of this list is to try and create the features necessary to make > >Perl the best language for data crunching around, while keeping it > Perlish. > > "Easy things should be easy". > > For example to

Re: New variable type: matrix

Chaim Frenkel wrote: > > >>>>> "CS" == Christian Soeller <[EMAIL PROTECTED]> writes: > > CS> The other problem with arrays is: how do we deal with functions that > CS> take multiple piddle arguments if they are arrays: > > CS>@re

Re: drop type indicators for typed variables

"David L. Nicol" wrote: > > > Christian Soeller wrote: > > > > > > The other problem with arrays is: how do we deal with functions that > > > take multiple piddle arguments if they are arrays: > > > > > >@result = integrate @x,

Re: New variable type: matrix

Chaim Frenkel wrote: > > The current thinking in -internals is that list flattening will be delayed > to as late as possible. > > One possiblity would be that only @_ would do any flattening. It would > walk each argument with an appropriate iterator to return the flattened > list. > > A param

Re: Proposed RFC for matrix indexing and slicing

Dan Sugalski wrote: > >Meanwhile we all go rambling around on cross-threads and come up > >with no coherent set of proposals. > > So? If the idea has merit, it'll make it into one or more RFCs, and Larry's > rather good at making things coherent. If it just putters around for a > while on the li

Re: New variable type: matrix

Jeremy Howard wrote: > Basically, I want to be able to create a list ref of list refs, specify a > data type (eg 'int') and attributes of ':compact' or ':sparse', and have the As Dan Sugalski suggested it seems not a good idea to bring in the list of list ref into the proposal. Why does it have

Re: RFC 148 (v1) Add reshape() for multi-dimensional array reshaping

Karl Glazebrook wrote: > > 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. I see a number of problems with the current (scalar) PDL objects being turned (essentially) into perl arrays in perl6. 1) How do y

Re: New variable type: matrix

Doug Hunt wrote: > What I meant to say (but failed, alas) was that I support the idea for a > new perl variable type called compact array: > > $foo -- scalar > @foo -- array > %foo -- hash > ^foo -- compact array (or whatever notation) I seem to remember that ^ was in the process of being hig

Re: multidim. containers

Dan Sugalski wrote: > If you want efficiency, n-dimensional arrays really need to be a concrete > data type all of their own. That way one big block of memory can be > allocated and, if it's a typed array, properly sized. I wholeheartedly agree ;) > > That doesn't mean that n-dimensional array

Re: New variable type: matrix

Doug Hunt wrote: > But I would like to speak up in support of Baris' idea. I have long > found it > confusing (both to myself and to those I must explain my code to) the > mix of > pdl multi-dimensional lists (lists of refs to lists) and PDLs, which > appear to be scalars. I was even asked once