MtxVec Object Hierarchy

The MtxVec class hierarchy is designed around a layered inheritance tree. Understanding which methods belong to which level helps navigate the 12,000+ member API.

Inheritance tree:

TMtxVec (abstract base)
├── TDenseMtxVec (dense storage)
│   ├── TVec (1D vector, pool-managed)
│   │   └── TVecInt (integer vector, pool-managed)
│   └── TMtx (2D matrix, pool-managed)
│       └── TMtxInt (integer matrix, pool-managed)
└── TMtxVecInt (integer base)
    ├── TVecInt
    └── TMtxInt

Value type wrappers (automatic lifetime, operator overloading):

Vector   → wraps TVec    (record with implicit operator)
Matrix   → wraps TMtx    (record with implicit operator)
VectorInt → wraps TVecInt
MatrixInt → wraps TMtxInt

TVecInt and TMtxInt are pool-managed like TVec/TMtx, and their value-type wrappers VectorInt/MatrixInt convert to them implicitly (just as Vector/Matrix convert to TVec/TMtx).

What each level provides:

Level	Key methods	Purpose
`TMtxVec`	Sin, Cos, Exp, Ln, Add, Mul, Sub, Div, Abs, Sqrt, Power, ...	Element-wise math on any container
`TDenseMtxVec`	FFT, IFFT, DotProd, CumSum, Difference, Sort, ...	Operations requiring dense storage
`TVec`	Size(Int32), Values1D, SetSubRange, BlockInit/BlockNext/BlockEnd	1D-specific sizing, direct access, block processing
`TMtx`	Size(rows,cols), Values, Transp, LUSolve, Eig, SVD, Mul(matrix)	2D-specific operations, linear algebra

Why signatures use base types:

A method accepting TMtxVec can receive Vector, Matrix, TVec, TMtx, or any derived type.
A method accepting TDenseMtxVec can receive any dense container.
This polymorphism is by design — element-wise operations work on any shape because vectors and matrices share the same contiguous memory layout.

GPU types (separate hierarchy):

TOpenCLVec → clVector (1D GPU)
TOpenCLMtx → clMatrix (2D GPU)

GPU types mirror the CPU API but execute on OpenCL-capable devices.