To get the counts, I had to iterate over the lines. There might be a better solution, I'm not a PDL expert. The resulting piddle has the count as the last element:

#!/usr/bin/perl
use warnings;
use strict;

use PDL;

my $p = pdl(
    [0, 1, 2],
    [3, 4, 5],
    [6, 7, 8],
    [0, 1, 2],
    [0, 1, 2],
    [6, 7, 8],
    [0, 1, 10]);

my $u = $p->uniqvec;

my @r;
for my $i (0 .. $u->dim(1) - 1) {
    my $vec = $u->slice(':', $i);
    my $matches = $p == $vec;
    push @r, [ $matches->andover->sum ];
}

print $u->glue(0, pdl(@r));
[download]

[
 [ 0  1  2  3]
 [ 0  1 10  1]
 [ 3  4  5  1]
 [ 6  7  8  2]
]
[download]

($q=q:Sq=~/;[c](.)(.)/;chr(-||-|5+lengthSq)`"S|oS2"`map{chr |+ord
}map{substrSq`S_+|`|}3E|-|`7**2-3:)=~y+S|`+$1,++print+eval$q,q,a,
[download]

Since using uniqvec leads to subsequent manual looping over original and perhaps a bit too much additional math, then maybe if, looks like, we are out of luck with elegant vectorized solution anyway, let's find unique lines directly. The @keys are not required to be stored, they can be extracted again using @index, or even get_dararef can be called on severed $uniq and then large string can be split into equal chunks. I didn't investigate what would be more efficient. If data are very large, then maybe md5( $$ref ) could be used. Not sure if appending counts to data is a good idea, but it's in final line, anyway.

All this assuming that order of unique lines should be preserved, and that your data are already efficiently put into large piddle (or, otherwise, if matrix is built line by line, the lookup table can be more easily constructed in the same loop.)

use strict;
use warnings;
use feature 'say';
use PDL;

my $x = pdl
[
 [0, 1, 2],
 [3, 4, 5],
 [6, 7, 8],
 [0, 1, 2],
 [0, 1, 2],
 [6, 7, 8],
];

my @index;
my @keys;
my %count;

for ( 0 .. $x-> dim( 1 ) - 1 ) {
    my $ref = $x-> slice( [], $_ )-> get_dataref;
    next if $count{ $$ref } ++;
    push @index, $_;
    push @keys, $$ref;
}

my $uniq   = $x-> dice( 'X', pdl \@index );
my $counts = pdl @count{ @keys };

say $uniq;
say $counts;
say $uniq-> append( $counts-> transpose );
[download]

Output:

>perl pdl180220.pl

[
 [0 1 2]
 [3 4 5]
 [6 7 8]
]

[3 1 2]

[
 [0 1 2 3]
 [3 4 5 1]
 [6 7 8 2]
]
[download]

Hi,

Thanks for the quick replies all. Thanks to choroba for linking to uniqvec, which I must have missed during reading the documentation.

Thanks to vr for the good example code, this clears things up a bit. I came to the conclusion that my whole approach was incorrect (which I kind of expected when learning PDL).

I am building up the matrix vector by vector, so if we consider each vector as a single entity (which is what I am doing), then rather than a 2D matrix of vectors, in essence I have a 1D vectors of entities. Therefore, I am choosing to build the lookup table during creation.

Many thanks all.

A really good PDL library for operating on vectors is PDL::VectorValued. Indeed, it's so good that we're just discussing incorporating it into main PDL (see https://github.com/moocow-the-bovine/PDL-VectorValued/issues/5).

The particular operation you'd want here is probably vsearchvec.

#here's an array
my @a = (1,2,3);

#now it's a string:
my $string = join '', @a; 

#here's another array

my @b;

#Now the array values your looking for become an array element.
#Increment when those values come up again.
$b[$string]++;

# so $b[123] now = 1

#Leading zeroes disappear, so you could add a 1 to the front of $strin
+g.
$string = '1' . join '', @a;
$b[$string]++;
# so $b[1123] now = 1

#yeah. that'll work

#I might write the whole thing as:
my @a = all your stuff as little array refs from wherever
my @b = the answers you want;
for (@a)
   my $string = '1' . join '', @$_; 
   $b[$string]++
}

#after that, you could copy to an array of tuples:
# e.g., $c[2] = (["123"],[5]); #strip that extra '1' and turn to strin
+g?
#       $c[2] = (["info"], [number of times you find it]);
# might make it easier to play with.

#would %b be faster than @b? I prefer arrays, but that's my bias. 
#$b{$string}++ would certainly work. But, is it as easy to muck about 
+with?
#that extra '1' for referencing the elements does bother me a bit.
[download]