PDL::Indexing 2.4.3

PDL::Indexing Perl module contains a tutorial on how to index piddles.

This manpage should serve as a first tutorial on the indexing and threading features of PDL.

This manpage is still in alpha development and not yet complete. "Meta" comments that point out deficiencies/omissions of this document will be surrounded by square brackets ([]), e.g. [ Hopefully I will be able to remove this paragraph at some time in the future ]. Furthermore, it is possible that there are errors in the code examples. Please report any errors to Christian Soeller (c.soeller@auckland.ac.nz).

Still to be done are (please bear with us and/or ask on the mailing list, see PDL::FAQ):

document perl level threading
threadids
update and correct description of slice
new functions in slice.pd (affine, lag, splitdim)
reworking of paragraph on explicit threading

Indexing and threading with PDL

A lot of the flexibility and power of PDL relies on the indexing and looping features of the perl extension. Indexing allows access to the data of a pdl object in a very flexible way. Threading provides efficient implicit looping functionality (since the loops are implemented as optimized C code).

Pdl objects (later often called "pdls") are perl objects that represent multidimensional arrays and operations on those. In contrast to simple perl @x style lists the array data is compactly stored in a single block of memory thus taking up a lot less memory and enabling use of fast C code to implement operations (e.g. addition, etc) on pdls.

pdls can have children

Central to many of the indexing capabilities of PDL are the relation of "parent" and "child" between pdls. Many of the indexing commands create a new pdl from an existing pdl. The new pdl is the "child" and the old one is the "parent". The data of the new pdl is defined by a transformation that specifies how to generate (compute) its data from the parents data. The relation between the child pdl and its parent are often bidirectional, meaning that changes in the childs data are propagated back to the parent. (Note: You see, we are aiming in our terminology already towards the new dataflow features. The kind of dataflow that is used by the indexing commands (about which you will learn in a minute) is always in operation, not only when you have explicitly switched on dataflow in your pdl by saying $a->doflow. For further information about data flow check the dataflow manpage.)

Another way to interpret the pdls created by our indexing commands is to view them as a kind of intelligent pointer that points back to some portion or all of its parents data. Therefore, it is not surprising that the parents data (or a portion of it) changes when manipulated through this "pointer". After these introductory remarks that hopefully prepared you for what is coming (rather than confuse you too much) we are going to dive right in and start with a description of the indexing commands and some typical examples how they might be used in PDL programs. We will further illustrate the pointer/dataflow analogies in the context of some of the examples later on.

There are two different implementations of this ``smart pointer relationship: the first one, which is a little slower but works for any transformation is simply to do the transformation forwards and backwards as necessary. The other is to consider the child piddle a ``virtual piddle, which only stores a pointer to the parent and access information so that routines which use the child piddle actually directly access the data in the parent. If the virtual piddle is given to a routine which cannot use it, PDL transparently physicalizes the virtual piddle before letting the routine use it.

Currently (1.94_01) all transformations which are ``affine, i.e. the indices of the data item in the parent piddle are determined by a linear transformation (+ constant) from the indices of the child piddle result in virtual piddles. All other indexing routines (e.g. ->index(...)) result in physical piddles. All routines compiled by PP can accept affine piddles (except those routines that pass pointers to external library functions).

Note that whether something is affine or not does not affect the semantics of what you do in any way: both

$a->index(...) .= 5;
$a->slice(...) .= 5;

change the data in $a. The affinity does, however, have a significant impact on memory usage and performance.