No problem. Glad to help. The documentation for the basic PDL operators is in PDL::Ops, which you can get by doing
pdl> ?ops That will show you all the basic math operators, most of which have both named functions (e.g., 'divide'), overloaded operators (e.g., '/'), and can modify the original piddle in place if you use the 'inplace' syntax. So as long as your piddles have the same dimensions, or are at least thread-compatible (i.e., have the same 0th dimension, which is what the example I gave you did), it will work. If you play with '<', and '>' you'll see that the test is done element-by-element, just like it was for '==' (so it's not a lexical comparison). If you want to know if all elements of $P are less than the corresponding element of $test, then you'll need to collapse along the 0th dimension. Same for if you want to know if only some of the elements of $P are less than $test. pdl> ??sort or pdl> apropos sort searches the documentation for functions whose name or description matches 'sort'. If you're new to PDL, check out the PDL Book, which you can download from pdl.perl.org. That and the "First Steps" document should be enough to give you the lay of the land. As you've noticed, the mailing list is also pretty responsive. cheers, Derek On Nov 14, 2014, at 11:37 AM, LYONS, KENNETH B (KENNETH) <k...@research.att.com> wrote: > Hey, thanks. This looks exactly right. I hadn’t realized that the == > operator would work with *2* PDL operands! (boy do I wish this stuff had > better documentation!). > > I’ll try it out, but from the looks of what you presented here, this looks > like just the ticket. > > Do you know if you can do the same with the > operator? The qsortvec > function sorts vectors in lexical order, so I’d guess that if == works then > the > and < operators probably work with 2 PDL operands as well (again > assuming lexical ordering)? > > Ken > > p.s. Interesting that you’re the one who replied. I got my physics PhD at > Boulder, eons ago. > > Ken > > > From: Derek Lamb [mailto:de...@boulder.swri.edu] > Sent: Friday, November 14, 2014 1:26 PM > To: LYONS, KENNETH B (KENNETH) > Cc: perldl@jach.hawaii.edu > Subject: Re: [Perldl] matching vectors inside a PDL > > Hi Kenneth, > > I did this. The last line has what you're looking for in one line, but the > stuff leading up to it shows my thought process: > > pdl> $P = rint(random(3,10)*5) > > pdl> p $P > > [ > [4 1 4] > [5 4 2] > [1 2 2] > [0 3 0] > [1 1 2] > [2 1 2] > [4 0 1] > [4 1 4] > [0 1 4] > [4 2 3] > ] > > pdl> $test = pdl(4,1,4) #turns out that [4 1 4] turns up twice, so I'll just > pick that for now > > pdl> p $P==$test > > [ > [1 1 1] > [0 0 0] > [0 0 0] > [0 0 0] > [0 1 0] > [0 1 0] > [1 0 0] > [1 1 1] > [0 1 1] > [1 0 0] > ] > > pdl> p sumover($P==$test) > [3 0 0 0 1 1 1 3 2 1] > pdl> p sumover($P==$test)==$P->dim(0) > [1 0 0 0 0 0 0 1 0 0] > pdl> p $findresult = which(sumover($P==$test)==$P->dim(0)) > [0 7] > > Is that what you're looking for? > > Actually, a little cleaner way is to do > > pdl> p $findresult = which(andover($P==$test)) > [0 7] > > cheers, > Derek > > On Nov 13, 2014, at 6:20 PM, LYONS, KENNETH B (KENNETH) > <k...@research.att.com> wrote: > > > I need to be able to match a vector inside a PDL, and can’t find a way to do > it. The existence of qsortvec and uniqvec functions implies that such a > comparison function exists (since you’d need to do that to sort) but the > documentation doesn’t give any info on it. More specifically, if I have an > nxm PDL $P, containing vectors of length n in the first dimension, and an nx1 > PDL representing a test vector, $test, I want to be able to get the indices > along the 2nd dimension where the vector in the PDL matches the test one. > > I would expect that such a function, which I’ll provisionally name findveci, > would operate as > $findresult = $P->findveci($test) > Where $findresult would be a 1-dimensional PDL giving the set of indices > along the second dimension of $P that match the vector $test. > > I should note that a similar purpose would be served by a function uniqveci > (which, although an obvious extension of the set that are available, also > seems not to exist), since you could combine that with qsortvec to do what > I’m talking about. At present, I’ve resorted to pulling the vectors into > perl lists and doing the matching there. But that’s far slower, and it seems > wrong to have to do it that way. > > Any suggestions? > _______________________________________________ > Perldl mailing list > Perldl@jach.hawaii.edu > http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
_______________________________________________ Perldl mailing list Perldl@jach.hawaii.edu http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
