[Perldl] Large Number Support?

David Mertens dcmertens.perl at gmail.com
Fri Feb 10 13:23:51 HST 2012

On Fri, Feb 10, 2012 at 3:08 PM, Judd Taylor <judd.t at orbitalsystems.com>wrote:

>  I'd also like to chime in here and say that I think PDL's support of
> data types is too limited right now. It should at least support long double
> formats. It would be more than awesome if PDL would work on the full range
> of numeric data types commonly used in scientific software and data
> formats, but it doesn't even come close currently.
> Some relevant lists:
> HDF5:
> http://www.hdfgroup.org/HDF5/doc/UG/11_Datatypes.html
> HDF:
> http://www.hdfgroup.org/training/HDFtraining/UsersGuide/Fundmtls.fm3.html
> NetCDF:
> http://www.unidata.ucar.edu/software/netcdf/docs/netcdf/CDL-Data-Types.html
> It would make interfacing to these very common formats stupid easy without
> any additional memory or data storage expense that you get from using the
> current PDL interfaces to these formats...
> -Judd
>  ____________________________
> Judd Taylor
> Software Engineer
> Orbital Systems, Ltd.
> 3807 Carbon Rd.
> Irving, TX 75038-3415
> judd.t at orbitalsystems.com
> (972) 915-3669 x127
>   ------------------------------

Adding new C data types (like long double) to the core is relatively easy.
At the moment there are some silly holes, such as unsigned chars: only
signed bytes are supported. I know of no reason for this. The same is true
for long doubles.

The problem with adding new data types is that every single threadloop that
doesn't explicitly state GenericTypes will have a copy of the code
generated and compiled for each data type. We have seven data types at the
moment, so adding unsigned chars and long doubles wouldn't have a huge
impact on the code size. However, we might also consider adding signed long
(32 bit ints) and signed long-long (64 bit ints). That takes us from seven
to 11. We should add the types and see how much this increases the code
size. It may not be unreasonable.

As for adding additional types, like complex numbers or Large numbers,
those are more difficult to accommodate. Craig and I will be going through
the core for a cleanup leading up to v2.5 (hopefully we'll get started some
time this summer), so maybe after that we can address non-native types at
that time. However, adding anything that's not known to C will be Very
Difficult with PDL, as I understand it.

One possible work around, which I've thought about but have no code for it,
is a sort of PDL::Pointer type. But that would require a fair amount of
core hacking before we have it working.


 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.jach.hawaii.edu/pipermail/perldl/attachments/20120210/6ec57479/attachment.html>

More information about the Perldl mailing list