# minieigen documentation¶

## Overview¶

Todo

Something concise here.

## Examples¶

Todo

Some examples of what can be done with minieigen.

## Naming conventions¶

• Classes are suffixed with number indicating size where it makes sense (it does not make sense for minieigen.Quaternion):
• minieigen.Vector3 is a 3-vector (column vector);
• minieigen.Matrix3 is a 3×3 matrix;
• minieigen.AlignedBox3 is aligned box in 3d;
• X indicates dynamic-sized types, such as minieigen.VectorX or minieigen.MatrixX.
• Scalar (element) type is suffixed at the end:
• nothing is suffixed for floats (minieigen.Matrix3);
• i indicates integers (minieigen.Matrix3i);
• c indicates complex numbers (minieigen.Matrix3c).
• Methods are named as follows:
• static methods are upper-case (as in c++), e.g. minieigen.Matrix3.Random;
• nullary static methods are exposed as properties, if they return a constant (e.g. minieigen.Matrix3.Identity); if they don’t, they are exposed as methods (minieigen.Matrix3.Random); the idea is that the necessity to call the method (Matrix3.Random()) singifies that there is some computation going on, whereas constants behave like immutable singletons.
• non-static methods are lower-case (as in c++), e.g. minieigen.Matrix3.inverse.
• Return types:
• methods modifying the instance in-place return None (e.g. minieigen.Vector3.normalize); some methods in c++ (e.g. Quaternion::setFromTwoVectors) both modify the instance and return the reference to it, which we don’t want to do in Python (minieigen.Quaternion.setFromTwoVectors);
• methods returning another object (e.g. minieigen.Vector3.normalized) do not modify the instance;
• methods returning (non-const) references return by value in python

## Limitations¶

• Type conversions (e.g. float to complex) are not supported.
• Methods returning references in c++ return values in Python (so e.g. Matrix3().diagonal()[2]=0 would zero the last diagonal element in c++ but not in Python).
• Many methods are not wrapped, though they are fairly easy to add.
• Conversion from 1-column MatrixX to VectorX is not automatic in places where the algebra requires it.
• Alignment of matrices is not supported (therefore Eigen cannot vectorize the code well); it might be a performance issue in some cases; c++ code interfacing with minieigen (in a way that c++ values can be set from Python) must compile with EIGEN_DONT_ALIGN, otherwise there might be crashes at runtime when vector instructions receive unaligned data. It seems that alignment is difficult to do with boost::python.
• Proper automatic tests are missing.