Adding a new type, as linked above, is a matter of creating extra options in the various places where PDL types live: conversion functions in Perl-land, type-specifiers for various PDL functions in Perl-land, type-qualifiers in PP function signatures, etc. Until about 2.035, it took extra manual stuff to hook up further types, including the (it turned out unnecessary) manually-hardcoded casting between various C types (it turned out the C standard and compiler can handle that all 100% fine).
With the changes there, those manual activities became minimal, which made it easy(ish) to add further C types like C99 complex numbers, the rest of the integer types, and long doubles. However, and this is quite important, PP only provides text-expansion of provided Code (etc) chunks into parts of switch statements inside the various functions that make up the API of a PDL operation. The expanded text still needs to compile as C.
This would mean that to support big ints, or MPFR, something would need to turn atomic C operations on C atomic-type (as I am calling them here) numbers (+,-,*,/,etc) into the appropriate version for those non-atomic types. That would involve parsing the actual C and making substitutions. This is not impossible, and using e.g. Pegex would make it manageable, but it would be significant work. On the plus side, it might facilitate moving to using e.g. OpenCL. See https://github.com/PDLPorters/pdl/issues/349 for more and/or to contribute! | [reply]
[d/l]
[select] |
but $x=pdl(50137.685706) should create a piddle and, as I showed in my previous post, this works and sucessfully hold the whole number?! | [reply]
[d/l] |
