#180 axisvals wraps for short types w big piddles

core (120)

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;
p $coords->minmax;
0 255

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.


  • Craig DeForest

    Craig DeForest - 2008-07-08
    • status: open --> closed-fixed
  • Craig DeForest

    Craig DeForest - 2008-07-08

    Logged In: YES
    Originator: NO

    Yep, there appears to be no other behavior that is less surprising. I have updated the xvals/yvals/zvals/ndcoords documentation to reflect this caveat.

    There is another quirk: ndcoords() appears to be a strict superset of axisvals(). I have merged the two, so axisvals() will now behave exactly like it did before when called the same way, but will also support the ([TYPE],@dimlist) style of calling.



Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks