SF feature request #82 - Alternate type behaviour for xvals, yvals, zvals

[mohawk2]

https://sourceforge.net/p/pdl/feature-requests/82/

@zmughal writes:
I noticed the caveat for xvals, yvals, and zvals regarding the type:

CAVEAT:

If you use the single argument piddle form (top row in the usage table) the
output will have the same type as the input; this may give surprising
results if, e.g., you have a byte array with a dimension of size greater
than 256. To force a type, use the third form
Wouldn't it make more sense to have the default one-argument version use the
PDL_IND datatype? I think this would be better as it would fit with the
principle of least astonishment.

Chris writes:
Makes sense to me. The PDL_Indx data type is a recent addition from the work to support 64bit indexing. Now that it exists, this change would be a logical update.

This seems like the correct thing to do but it would break back compatibility with existing usage. I'm not sure if the implicit type conversion would sufficiently hide the change to the API. Thoughts, anyone?

[mohawk2]

A problem with this is that xlinvals uses xvals, and wants to basically do floating-point calculations from it. A better choice is almost certainly to have a minimum type (probably double) and upgrade the type to be that.

[zmughal]

Using at least double would fix the caveat for most inputs since with 64-bit IEEE 754 double it would support [0, 2⁵³]. That would be a caveat, but it would have a smaller effect than the current one.

Perhaps use double for the existing xvals, etc. to avoid API changes and for optimization. If somebody needs it (so not now), it would be trivial to add an xvals_indx which does the same but with indx if only working with integers.

[karlglazebrook]

yes the (my!) whole original point behind xvals etc was to make these sort of calculations (things like centroids) easy.

[mohawk2]

Fixing this is connected to Craig's thoughts on the sf.net origin for #217 (reshape behaviour inplace vs mv).

[mohawk2]

As of f49ac06 xvals et al all return at least a double.

[djerius]

This change breaks code which requires xvals et al. to do what the documentation promised, namely return the type which was requested. That's a major API breakage (with no updates to the documentation)

It's now turning explicit requests for shorts and floats into doubles, which is definitely not what we want. This is doubling the memory requirements, and breaks long working code which passes ndarrays to C functions which require floats or shorts.

By all means make the default a double, but don't ignore a specific request for a type.

EDIT: Apologies for the tone. Long day...

[djerius]

Sorry, here's some code:

$ perl -MPDL -E 'say xvals(short,2)->info'
PDL: Double D [2]