That is a very interesting idea, Chris. Hmmm, I wonder if something like that would make ranges easier/faster?
On Feb 12, 2012, at 11:55 AM, chm wrote: > [Changing the topic in reply...] > > Adding support for arbitrary data types > is something I would like to see. It should > be possible to have a piddle of "something" > as a regular array of that "something". > > This is something that would require an > update (at least) to the PDL::PP code generation. > A specific case of interest would be piddles > of pointers that would allow for indirection > in pdl data sets. > > The trick would be to implement these in a > simple, efficient, and fast code. > > --Chris > > On 2/10/2012 6:23 PM, David Mertens wrote: >> On Fri, Feb 10, 2012 at 3:08 PM, Judd Taylor<[email protected]>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 >>> >>> [email protected] >>> (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. >> >> David > > _______________________________________________ > Perldl mailing list > [email protected] > http://mailman.jach.hawaii.edu/mailman/listinfo/perldl > _______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
