Future Work

This page lists some issues we hope to address and features we’d like to add in future versions of the CML.

Naming Convention

We chose lower case with underscores for the basic math classes and associated functions, as this is a common convention for low-level library code.

This convention ended up propagating into the higher-level math code as well, resulting in some fairly lengthy function names. This problem will be addressed in future versions of the CML.

Transform Function Syntax

CML transform functions currently follow (loosely) the convention used by the DirectX math library. Transform functions are global and non-member, and take the target object as a reference argument, e.g.:

matrix44f_r m;
matrix_rotation_world_x(m, angle);

This is somewhat awkward, as it requires the variable to be declared before it can be used. In future versions of the CML we hope to revise the architecture to support more concise and intuitive syntax, e.g.:

matrix44f_r m = rotation_world_x(angle);

Vector and Quaternion Normalization

The current version of the CML supplies only ‘basic’ normalization functions for vectors and quaternions.

However, it can be useful to have a normalization function return the length of the target prior to normalization, check the magnitude and indicate to the caller whether the normalization succeeded, and so on. We hope to include these features in future versions.


The CML randomization utility functions are not intended to serve as a substitute for sophisticated libraries such as boost::random. However, we would still like to improve and expand their functionality, in particular by allowing for ‘pluggable’ PRNGs and offering better support for random unit-length vectors and quaternions.

Matrix Inversion

We hope to add more options for matrix inversion, such as error reporting when the determinant is of small magnitude.

Also, although inversion of small matrices (N <= 4) is quite efficient, inversion of matrices with size N > 4 currently involves some internal memory allocation to keep track of pivoting. We realize this may be an unacceptable cost in some contexts and plan to address the problem in the future (possibly by allowing the client to supply his or her own storage for the pivot data).

Library Extensions

Once the CML matures, add-on libraries or library extensions (perhaps in a cmlx:: namespace) could be developed, offering a much wider range of functionality. Presumably these libraries would follow the CML’s philosophy of customizability.

For example, some work has already been done on a curve library built on the CML. The complete library would offer base classes for curves and multicurves in 2-d and 3-d, along with derived classes implementing various curve types such as NURBS and Bezier curves of varying degrees. There would also be support for various frame types (Frenet, fixed-reference, parallel transport) and arc-length reparameterization (perhaps making use of other cmlx:: libraries for integration and root-finding).


General revisions, modifications, and cleanup on the ‘todo’ list include:

  • Adding some additional useful utility functions, e.g. is_power_of_2() and next_power_of_2().
  • Support for quaternion ‘squad’ interpolation.
  • Using std:: algorithms in place of hand-written code where performance can be assumed to be equivalent (e.g. min_element()).
  • Cleaning up a few questionable algorithmic choices, such as naive use of the modulus operator to generate random integers.
  • Using a lightweight custom class for the internal storage of dynamic vectors and matrices rather than std::vector.
  • Evaluating the usefulness and safety of the external storage policy.
  • Addressing various compiler issues and eliminating compiler warnings where possible.
  • General cleanup of the internal architecture to remove redundancy and simplify the code base.
  • Doxygen-generated documentation.