[Perldl] extending PDL data type support

[Craig DeForest]

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<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.
>> 
>> David
> 
> _______________________________________________
> Perldl mailing list
> Perldl at jach.hawaii.edu
> http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
>