#82 Alternate type behaviour for xvals, yvals, zvals

open
nobody
None
5
2016-04-23
2014-06-20
No

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.

Regards,
- zaki

Discussion

  • Chris Marshall

    Chris Marshall - 2014-06-20

    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.

     
    • Zakariyya Mughal

      Bug #180 is a related bug that was closed earlier.

      • zaki
       
  • Zakariyya Mughal

    Bug #180 is a related bug that was closed earlier.

    Regards,
    - zaki

     
    Last edit: Zakariyya Mughal 2014-06-20
  • Chris Marshall

    Chris Marshall - 2015-09-29

    With full 64bit support and PDL_Indx data type, I suggest making this change for PDL-2.014.

     
  • Chris Marshall

    Chris Marshall - 2016-04-23

    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?

     

Log in to post a comment.

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

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks