Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer
 
PerlMonks  

Re: PDL range on 4-d piddles

by jo37 (Deacon)
on Oct 19, 2023 at 20:14 UTC ( [id://11155075] : note . print w/replies, xml ) Need Help??


in reply to PDL range on 4-d piddles

As suggested by choroba, I upgraded to 2.084. It doesn't crash anymore, but it does not seem to work right. I have a little problem with 4-d piddles, though - they are just a bit beyond my imagination. However, there are things where you just can feel they are wrong. So let's take a 5x5x5x5 piddle filled with the sequence 0..(5^4-1). From this piddle we take a 2x2x2x2 slice around every piddle element and take take the sum over the slice's elements. Obviously, no such sum can ever be less than 28 as the sum of 0..7. However:

#!/usr/bin/perl use v5.24; use warnings; use PDL; my $q = sequence(5,5,5,5); say 'q: ', $q->info; say 'ndcoords: ', ndcoords($q)->info; say 'range: ', $q->range(ndcoords($q), 2, 't')->info; say '2x2x2x2 sum:', $q->range(ndcoords($q), 2, 't')->reorder(4,5,6,7,0 +,1,2,3)->clump(4)->sumover; __DATA__ q: PDL: Double D [5,5,5,5] ndcoords: PDL: Double D [4,5,5,5,5] range: PDL: Double D [5,5,5,5,2,2,1,5] 2x2x2x2 sum: [ [ [ [ 0 1 2 3 4] [ 5 6 7 588 296] [604 612 620 628 316] [644 652 660 668 336] [332 336 340 344 173] ] [ [724 732 740 748 376] [764 772 780 788 396] [804 812 820 828 416] [844 852 860 868 436] [432 436 440 444 223] ] ...

Update:

The problem is much easier to see if we use a all-ones piddle and take periodic boundaries. Then all slices are made of ones and the sum over a 2^D slice is (or: should be) always 2^D.

However:

#!/usr/bin/perl use v5.24; use warnings; use PDL; my $q = ones(5,5,5,5); say 'q: ', $q->info; say 'ndcoords: ', ndcoords($q)->info; say 'range: ', $q->range(ndcoords($q), 2, 'p')->info; say '2x2x2x2 sum:', $q->range(ndcoords($q), 2, 'p')->reorder(4,5,6,7,0 +,1,2,3)->clump(4)->sumover; __DATA__ [ [ [ [9 9 9 9 9] [9 9 9 8 8] [8 8 8 8 8] [8 8 8 8 8] [8 8 8 8 8] ] [ [8 8 8 8 8] [8 8 8 8 8] [8 8 8 8 8] [8 8 8 8 8] [8 8 8 8 8] ] ...

Greetings,
-jo

$gryYup$d0ylprbpriprrYpkJl2xyl~rzg??P~5lp2hyl0p$

Replies are listed 'Best First'.
Re^2: PDL range on 4-d piddles
by etj (Deacon) on Jan 30, 2024 at 21:40 UTC
    Thanks to all for their investigation, and also for reporting this!

    This is indeed a fascinating problem. The reason why the higher-dim output ndarrays have dims that start with 1, then are powers of the original size, is because the pdl struct has a def_dims array, size 6. Straight after that is the def_dimincs (stride-size at each dimension), also size 6 (the API has code to allocate memory if >6 dims, clearly that's not getting called here). Both are being used, even though there are more than 6 dims. Reading the array of dims will therefore give data that starts out correct, then looks crackers. It's almost certainly a bug in the rangeb code, since higher-dim ndarrays surely get tested elsewhere and the API ought to be solid.

    Further discussion etc on the GitHub issue, but I thought I'd give an insight here into what's going on.

      The problem is now fixed (in the git repo), by deleting one line. See the GitHub issue for more details!