PDL Advent calendar 2024 tracker

From PDLPorters/pdl#34, better to have separately:

@duffee writes: I'm starting to think that a blog post using Test::PDL to test whether I truely understand how a $matrix * $vector operation works. (Advent calendar warning)

As a starter for an Advent posting, the newly-incorporated Test::PDL, which I'm using to replace all tapprox and nearly all instances of these constructs in the codebase:

• approx
• ok all($x == $y)
• is_deeply [$p->unpdl], [...]
• ok sum(abs($out-$in)) < 1e-4
• is $out == $in, 1
• ok tapprox(...)
• ok all approx(...)
• ok all($x == $y)
• is( int(at(sum($c-$ans))), 0, "conv2d()" )
• ok +($ans[0] == 50) && ($ans[1] == 1) && ($ans[2] == 2)

... is really good. It checks all types (unless you say not to) and dims are identical, whether NaNs/badvalues/infinities are all the same, and when something fails, you get a message like:

#   Failed test 'inplace sorting with bad values'
#   at Basic/t/ufunc.t line 56.
#     1/10 values do not match
#          got: Double   D [10]       (PB   ) [0 1 2 4 5 6 7 8 BAD BAD]
#     expected: Double   D [10]       (PB   ) [0 1 2 4 5 6 7 8 9 BAD]
# First <=5 values differ at: 
# [
#  [8]
# ]
# Those 'got' values: [BAD]
# Those 'expected' values: [9]

That one was from finding a bug in qsort that had lain hidden, because all(pdl('5 3 BAD') == pdl('5 BAD 2')) returns 1; the BAD does not make all return false because there are any true values.

The issue references PDLPorters/pdl#34 and describes a possible Advent-calendar blog post centered on Test::PDL. Start by reviewing that issue and the Test::PDL examples listed here; the scope and completion criteria need to be clarified before implementation can begin.