plucky (3) PDL::Types.3pm.gz

Provided by: pdl_2.099-3_amd64 bug

NAME

       PDL::Types - define fundamental PDL Datatypes

SYNOPSIS

        use PDL::Types;

        $pdl = ushort( 2.0, 3.0 );
        print "The actual c type used to store ushort's is '" .
           $pdl->type->realctype() . "'\n";
        The actual c type used to store ushort's is 'unsigned short'

DESCRIPTION

       Internal module - holds all the PDL Type info.  The type info can be accessed easily using the
       "PDL::Type" object returned by the type method as shown in the synopsis.

       Skip to the end of this document to find out how to change the set of types supported by PDL.

FUNCTIONS

       A number of functions are available for module writers to get/process type information. These are used in
       various places (e.g. "PDL::PP", "PDL::Core") to generate the appropriate type loops, etc.

   typesrtkeys
       Returns an array of keys of typehash sorted in order of type complexity

        pdl> @typelist = PDL::Types::typesrtkeys;
        pdl> print @typelist;
        PDL_SB PDL_B PDL_S PDL_US PDL_L PDL_UL PDL_IND PDL_ULL PDL_LL PDL_F PDL_D PDL_LD PDL_CF PDL_CD PDL_CLD

   ppdefs
       Returns an array of pp symbols for all real types. This informs the default "GenericTypes" for "pp_def"
       functions, making support for complex types require an "opt-in".

        pdl> print PDL::Types::ppdefs
        A B S U L K N P Q F D E

   ppdefs_complex
       Returns an array of pp symbols for all complex types.

        pdl> print PDL::Types::ppdefs_complex
        G C H

   ppdefs_all
       Returns an array of pp symbols for all types including complex.

        pdl> print PDL::Types::ppdefs_all
        A B S U L K N P Q F D E G C H

   typesynonyms
       return type related synonym definitions to be included in pdl.h .  This routine must be updated to
       include new types as required.  Mostly the automatic updating should take care of the vital things.

PDL TYPES OVERVIEW

       As of 2.065, PDL supports these types:

       SByte
           Signed 8-bit value.

       Byte
           Unsigned 8-bit value.

       Short
           Signed 16-bit value.

       UShort
           Unsigned 16-bit value.

       Long
           Signed 32-bit value.

       ULong
           Unsigned 32-bit value.

       Indx
           Signed value, same size as a pointer on the system in use.

       ULongLong
           Unsigned 64-bit value.

       LongLong
           Signed 64-bit value.

       Float
           IEEE 754 <https://en.wikipedia.org/wiki/IEEE_754> single-precision real floating-point value.

       Double
           IEEE 754 double-precision real value.

       LDouble
           A C99 "long double", defined as "at least as precise as a double", but often more precise.

       CFloat
           A C99 complex single-precision floating-point value.

       CDouble
           A C99 complex double-precision floating-point value.

       CLDouble
           A C99 complex "long double" - see above for description.

       As of 2.099, documentation for PDL::Type is separate. See there for more.

DEVELOPER NOTES ON ADDING/REMOVING TYPES

       You can change the types that PDL knows about by editing entries in the definition of the variable @types
       that appears close to the top of the file lib/PDL/Types.pm.

   Format of a type entry
       Each entry in the @HASHES array is a hash reference. Here is an example taken from the actual code that
       defines the "ushort" type:

         {
           identifier => 'US',
           onecharident => 'U',   # only needed if different from identifier
           ctype => 'PDL_Ushort',
           realctype => 'unsigned short',
           ppforcetype => 'ushort',
           usenan => 0,
           packtype => 'S*',
           defbval => 'USHRT_MAX',
           real=>1,
           integer=>1,
           unsigned=>1,
         },

       Before we start to explain the fields please take this important message on board: entries must be listed
       in order of increasing complexity. This is critical to ensure that PDL's type conversion works correctly.
       Basically, a less complex type will be converted to a more complex type as required.

   Fields in a type entry
       Each type entry has a number of required and optional entry.

       A list of all the entries:

       •   identifier

           Required. A short sequence of uppercase letters that identifies this type uniquely. More than three
           characters is probably overkill.

       •   onecharident

           Optional. Only required if the "identifier" has more than one character.  This should be a unique
           uppercase character that will be used to reference this type in PP macro expressions of the "TBSULFD"
           type - see "$T" in PDL::PP.

       •   ctype

           Required. The "typedef"ed name that will be used to access this type from C code.

       •   realctype

           Required. The C compiler type that is used to implement this type.  For portability reasons this one
           might be platform dependent.

       •   ppforcetype

           Required. The type name used in PP signatures to refer to this type.

       •   usenan

           Required. Flag that signals if this type has to deal with NaN issues.  Generally only required for
           floating point types.

       •   packtype

           Required. The Perl pack type used to pack Perl values into the machine representation for this type.
           For details see "perldoc -f pack".

       •   integer

           Required. Boolean - is this an integer type?

       •   unsigned

           Required. Boolean - is this an unsigned type?

       •   real

           Required. Boolean - is this a real (not complex) type?

       •   realversion

           String - the real version of this type (e.g. cdouble -> 'D').

       •   complexversion

           String - the complex version of this type (e.g. double -> 'C').

       Also have a look at the entries at the top of lib/PDL/Types.pm.

   Other things you need to do
       You need to check modules that do I/O (generally in the IO part of the directory tree). In the future we
       might add fields to type entries to automate this. This requires changes to those IO modules first
       though.

       You may also need to update any type macros in PP files (i.e. "$TBSULFD...") to reflect the new type - PP
       will throw an error if you have a "$T..." macro which misses types supported by the operation.