These are the outputs for my run (adding a print "perl version $]";print "PDL version $PDL::VERSION"; at the beginning to print the versions):

Mathematically speaking, a [3x3] x [3x2] is the right balance of dimensions for a successful matrix multiplication (resulting in a [3x2] matrix). The use of PDL::Matrix used to be the way to make PDL match mathematical order for the dimensions, but maybe they've changed that between 2.019 and 2.057. (I don't think I can test, because the Strawberry Perl PDL setup is rather dependent on the libraries that Strawberry bundles, and I don't know if upgrading PDL will work... maybe I'll try in a sandbox to avoid ruining my "main" installation).

I tried getting rid of the use PDL::Matrix, but then that gets rid of the mpdl command, causing errors during perl's compile stage, and I'm not sure what hoops I would need to jump through to make my script compatible with both 2.019 and 2.057.

Okay, 5.30.2 & PDL 2.021 and 5.32.1 & PDL 2.025 (the last pre-bundled Perl+PDL from Strawberry) both worked like my 5.30.0 & PDL 2.019.

But I was able to install PDL 5.080 with Perl 5.32.1, to get slightly newer PDL but slightly older Perl than you. But it showed the same dimensional difference.

So I did some debug to make it work without PDL::Matrix

<Reveal this spoiler or all in this thread>

This shows the 12-ish pixel error, but will hopefully work with your 2.057 (and definitely worked with my 2.080).

Minimal pair:

perl -MPDL -MPDL::Matrix -e '$m = mpdl [[2,0],[0,2]]; $v = vpdl [1,2];
+ print $m x $v'

[
 [2]
 [4]
]
[download]

vs.

perl -MPDL -MPDL::Matrix -e '$m = mpdl [[2,0],[0,2]]; $v = vpdl [1,2];
+ print inv($m) x $v'
Dim mismatch in matmult of [2x2] x [2x1]: 2 != 1 at /usr/lib64/perl5/v
+endor_perl/PDL/Primitive.pm line 274.
    PDL::matmult(PDL=SCALAR(0x5600a82130e0), PDL::Matrix=SCALAR(0x5600
+a8202ba0), PDL=SCALAR(0x5600a8d718c8)) called at /usr/lib64/perl5/ven
+dor_perl/PDL/Primitive.pm line 31
    PDL::__ANON__(PDL=SCALAR(0x5600a82130e0), PDL::Matrix=SCALAR(0x560
+0a8202ba0), "") called at -e line 1
[download]

This looks like a bug in PDL::Matrix, specifically with inv.

As now noted on pryrt's excellent bug report (thank you), this will still work as expected if you switch your inv($m) to $m->inv. This will then engage PDL::Matrix's overload of x, which is what you need here.

I would strongly encourage you not to use PDL::Matrix, because somewhat similar to PDL::Complex, it is full of gotchas. Even though after some head-scratching it became clear what exactly was happening here, it's not particularly clear how to fix it - a keyhole change to the Perl function PDL::MatrixOps::inv to make it ensure the output was the right class would resolve this exact issue. But since that uses lu_backsub for its work, and that is an eye-wateringly complicated Perl function as well, it will not be easy. That function's output variable comes from some PDL::Slices operations.

If someone were minded to at least use git bisect to identify the commit that broke it, that would be very helpful. Even better would be a pull-request that fixes this (obviously with a test, in t/matrix.t), that will use our amazing CI to check it doesn't break anything else in main PDL or known downstreams. A top tip would be that make coretest runs t/matrix.t, with a very minimal build otherwise that allows a very quick dev cycle.

As a hopefully practical (as well as better-performance, because it uses LAPACK) alternative, have you taken a look at PDL::LinearAlgebra?

kikichiyo,

Thanks for that SSCCE.

I included it in a bug report

The way to avoid needing mpdl is to transpose your data, and use pdl, and I would recommend doing so. But as observed elsewhere, there are almost certainly out-of-the-box solutions to this particular problem.