Simbody  3.5
CompositeNumericalTypes.h File Reference

The purpose of the CNT<T> class is to hide the differences between built-in numerical types and composite ones like Vec<3>. More...

Go to the source code of this file.

Classes

class  SimTK::CNT< K >
 Specialized information about Composite Numerical Types which allows us to define appropriate templatized classes using them. More...
 
struct  SimTK::CNT< K >::Result< P >
 
struct  SimTK::CNT< K >::Substitute< P >
 

Namespaces

 SimTK
 This is the top-level SimTK namespace into which all SimTK names are placed to avoid collision with other symbols.
 

Enumerations

enum  {
  SimTK::SCALAR_DEPTH = 0,
  SimTK::SCALAR_COMPOSITE_DEPTH = 1,
  SimTK::COMPOSITE_COMPOSITE_DEPTH = 2,
  SimTK::COMPOSITE_3_DEPTH = 3,
  SimTK::MAX_RESOLVED_DEPTH = COMPOSITE_3_DEPTH
}
 

Detailed Description

The purpose of the CNT<T> class is to hide the differences between built-in numerical types and composite ones like Vec<3>.

We can decorate all the composite types with whatever information we need, but we cannot add to the built-in types in the same way. So we define a templatized class CNT<T>, where the template parameter can be any composite numerical type whether built in or composite. Then CNT members are used to access information about class T. When T is a built-in, that information comes from specializations of CNT<T> for CNT<float>, CNT<std::complex<double>>, etc. When T is composite, CNT<T> acts as a pass-through to allow the composite type to provide its own information.

Here is the information that must be provided by a SimTK Composite Numerical Type T (or faked up for built-ins). Some of these are given friendly names and documented since they are useful in user code.

      Type             Meaning
      ---------------- --------------------------------------------------------
      TNeg             same shape as T, but elements are negated
      TReal            same shape as T, but with real elements
      TImag            same shape as T, with real elements from imaginary part
      TComplex         same shape as T, but with Complex or conjugate elements
      THerm            transpose of T, with Hermitian transposed elements
      TPosTrans        positional transpose of T; i.e., elements not transposed
      TSqHermT         type of ~T*T (default vector & matrix square; symmetric)
      TSqTHerm         type of T*~T (row square; symmetric)
      Scalar           the underlying scalar type (see below)
      ScalarNormSq     type of the "conjugate square" ~s*s of underlying scalar 
                         (always real)
      Substitute<E>::Type  
                       A CNT of the same shape and container type as this one,
                         but with elements of type E instead of ElementType.
                         Special case: if this CNT is a scalar then 
                         Substitute<E>::Type just returns E.
      Result<RHS>::Mul (Dvd,Add,Sub)
                       The type of the result of T op RHS, where RHS is *any* CNT
           ENUMS (all sizes are in units of T's elements)
      NRows            logical num rows in type T (i.e., num elements in a column)
      NCols            logical number of columns in type T
      RowSpacing       num elements from one row to the next (default 1)
      ColSpacing       num elements from one col to the next (default NRows for Mat)
      NPackedElements  minimum num elements it would take to store this data
      NActualElements  num elements covered by T due to element spacing
      NActualScalars   NActualElements * CNT<ElementType>::NActualScalars. This 
                         should be the physical spacing between array elements 
                         in an array containing this kind of CNT. Our big 
                         Matrix/Vector types guarantee this packing.
  
*
* The Scalar Types
* ----------------
* Here is a complete taxonomy of the scalar types we support.
*
* <scalar>         ::= quantity< unitType, <unitlessScalar> >
* <unitlessScalar> ::= <number> | negator< <number> >
* <number>         ::= <standard> | <conjugate>
* <standard>       ::= <real> | <complex>
*
* <real>           ::= float | double | long double
* <complex>        ::= std::complex< <real> >
* <conjugate>      ::= SimTK::conjugate< <real> >
*
* 

With this in hand, we can build a clean facility in which scalars, vectors, matrices, vectors of vectors, matrices of vectors of matrices, etc. can all be treated uniformly.