@kgryte In 3d, the incorrect strides were causing the offset and minmax indices to go out of bounds. I made some adjustments to the strides to ensure that the offset and minmax indices are within the buffer bounds. Hopefully, everything is now correct. Please review, thanks.

In 3d, the incorrect strides were causing the offset and minmax indices to go out of bounds.

@headlessNode To clarify, your comment concerns 3d or 4d?

@kgryte both. I tried different combinations of strides with 4d (for my understanding) and came to the above conclusion.

both. I tried different combinations of strides with 4d (for my understanding) and came to the above conclusion.

Still not sure I follow. Are you saying that there are bugs in the 3d tests that need to be fixed? Or that you needed to make modifications to the 3d tests to make them work for 4d?

In the current PR, you only have 4d test changes, so I am assuming the latter, but your comments suggest otherwise.

@headlessNode Did a review. Some of the strides were off, but I've now fixed these.

It may be worthwhile if you use the stdlib REPL to help inform the strides.

$ make repl

Once in the REPL,

In [1]: var shape2strides = require( '@stdlib/ndarray/base/shape2strides' );

In [2]: var blockSize = require( '@stdlib/ndarray/base/nullary-tiling-block-size' );

In [3]: var dt = 'float64';

In [4]: var bsize = blockSize( dt )
Out[4]: <number>

In [5]: shape2strides( [ bsize*2, 2, 1, 2 ], 'row-major' )
Out[5]: [ 4, 2, 2, 1 ]

In [6]: shape2strides( [ bsize*2, 2, 1, 2 ], 'column-major' )

From there, you can scale the strides as necessary to get non-contiguity, as desired.

@kgryte Thanks for the review and suggestion. Also sorry for the confusion, I should've phrased it differently. There's no bug, I was sharing my "findings" about why some strides work and some don't.