Skip to content

PDL Advent calendar 2024 tracker #68

@mohawk2

Description

@mohawk2

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Advent Calendarblog posts featuring fun bits of PDL

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions