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.
Skip to the end of this document to find out how to change the set of types
supported by PDL.
Support 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¶
return array of keys of typehash sorted in order of type complexity
ppdefs¶
return array of pp symbols for all known types
typefld¶
return specified field ($fld) for specified type ($type) by querying type hash
mapfld (in_value, in_key, out_key)¶
Map a given source field to the corresponding target field by querying the type
hash. This gives you a way to say, "Find the type whose $in_key is equal
to $value, and return that type's value for $out_key. For example:
# Does byte type use nan?
$uses_nan = PDL::Types::mapfld(byte => 'ppforcetype', 'usenan');
# Equivalent:
$uses_nan = byte->usenan;
# What is the actual C type for the value that we call 'long'?
$type_name = PDL::Types::mapfld(long => 'convertfunc', 'realctype');
# Equivalent:
$type_name = long->realctype;
As you can see, the equivalent examples are much shorter and legible, so you
should only use mapfld if you were given the type index (in which case the
actual type is not immediately obvious):
$type_index = 4;
$type_name = PDL::Types::mapfld($type_index => numval, 'realctype');
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::Type OBJECTS¶
This module declares one class - "PDL::Type" - objects of this class
are returned by the type method of a piddle. It has several methods, listed
below, which provide an easy way to access type information:
Additionally, comparison and stringification are overloaded so that you can
compare and print type objects, e.g.
$nofloat = 1 if $pdl->type < float;
die "must be double" if $type != double;
For further examples check again the type method.
- enum
- Returns the number representing this datatype (see
get_datatype).
- symbol
- Returns one of 'PDL_B', 'PDL_S', 'PDL_US', 'PDL_L',
'PDL_LL', 'PDL_F' or 'PDL_D'.
- ctype
- Returns the macro used to represent this type in C code (eg
'PDL_Long').
- ppsym
- The letter used to represent this type in PP code code (eg
'U' for ushort).
- realctype
- The actual C type used to store this type.
- shortctype
- The value returned by "ctype" without the 'PDL_'
prefix.
- badvalue
- The special numerical value used to represent bad values
for this type. See badvalue routine in PDL::Bad for more details.
- orig_badvalue
- The default special numerical value used to represent bad
values for this type. (You can change the value that represents bad values
for each type during runtime.) See the orig_badvalue routine in PDL::Bad
for more details.
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
Types.pm.PL (i.e. the file from which this module was generated).
Format of a type entry¶
Each entry in the @types 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
pdlctype => 'PDL_Ushort',
realctype => 'unsigned short',
ppforcetype => 'ushort',
usenan => 0,
packtype => 'S*',
},
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 upercase 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. If you don't know what I am talking about read
the PP manpage or ask on the mailing list.
- •
- pdlctype
Required. The "typedefed" 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".
Also have a look at the entries at the top of
Types.pm.PL.
The syntax is not written into stone yet and might change as the concept
matures.
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 should also make sure that any type macros in PP files (i.e.
"$TBSULFD...") are updated to reflect the new type. PDL::PP::Dump
has a mode to check for type macros requiring updating. Do something like
find . -name \*.pd -exec perl -Mblib=. -M'PDL::PP::Dump=typecheck' {} \;
from the PDL root directory
after updating
Types.pm.PL to check
for such places.