Analysis Software
Documentation for sPHENIX simulation software
 All Classes Namespaces Files Functions Variables Typedefs Enumerations Enumerator Friends Macros Groups Pages
Linear subspace definitions

Classes

class  Acts::detail::FixedSizeSubspace< kFullSize, kSize >
 

Detailed Description

All types in this group define a linear subspace of a larger vector space with the following properties: the subspace is defined by a set of axis indices in the full space, i.e. there is no need for a non-trivial projection matrix, all subspace axis indices are unique and there are no duplicated ones, and the set of axis indices must be ordered, i.e. the axis order in the subspace is the same as in the full space. The last requirement is not strictly required by the implementation, but is still added to simplify reasoning.

Only the size of the subspace are defined by the types at compile time. Which axes comprise the subspace is defined at runtime. This allows to use fixed-size computations (selected at compile time) but avoids the combinatorial explosion of also having to handle all possible combination of axes at compile time. This was tried previously and resulted in sizable resource consumption at compile time without runtime benefits.

All types are intentionally using size_t as their template values, instead of the more specific index enums, to reduce the number of templates. This is fully compatible as the index enums are required to be convertible to size_t.

All types intentionally only define the subspace but not how vectors and matrices are stored to avoid unnecessary coupling between components, i.e here between the pure definition and the storage.

All types provide .projectVector(...) and .exandVector(...) methods to convert to/from the subspace. They also provide .projector() and .expander() methods to create projection and expansion matrices if they are required explicitly. For the specific subspace requirements listed above, the projection and expansion matrices are transpose to each other. In the general case, this does not have to be the case and users are encouraged to use .projector() and .expander() instead of e.g. .projector().transpose().