RE: allaxisvals, axisvals, rvals, xlinvals,
xlogvals, xvals, ylinvals, ylogvals, yvals,
zlinvals, zlogvals, zvals
SUMMARY: *vals methods don't return correct
index values when the original piddle datatype
is too short to contain the axis extents.
This violates the principle of least surprise.
Working with some grayscale images (8bits)
I tried to calculate a function of pixel
coordinates as follows:
$im = ones(byte,640,480);
$coords = $im->allaxisvals;
The result is not what I expected to get: that
pixel (i,j) had allaxisvals [i,j]. It has the
value [i%256,j%256] instead. A look into the
docs show that all the *vals methods share this
property though at least the others indicate
that a piddle is being "filled" with the axis
which might hint that the index to datatype
coercion will happen---not so for allaxisvals.
This needs better docs on this "feature".
My typical use of these methods is to create
an index variable for field calculations. For
this use case the current implementation is
surprising and can be problematic, especially
when processing byte images as bytes to save
memory. It might be more reasonable to generate
index values of a type sufficiently large to
represent the largest possible index value.