Design principles

Release .zip Release .tar.gz Other versions

Design principles of VecTcl

VecTcl was designed in a way that integrates numerical computing tools as closely with Tcl as possible. VecTcl was defined to adhere to these general objectives:

  1. Ease of use
  2. Interoperability
  3. Generality
  4. No external dependencies
  5. Performance

These terms are interpreted within VecTcl in the following sense:

  1. Ease of use. The syntax should be as close to textbook notation of numerical mathematics as possible. This goal is largely achieved by borrowing a set of syntactical elements and essential functions from the array language supported by MATLAB and NumPy, two popular computational tools outside the Tcl world.
  2. Interoperability. Tcl already has a data type suitable for dealing with sequences of numbers, namely a list of integer or double values. Matrices and higher-rank tensors are most naturally expressed as nested lists. It is desirable, that the vector type can be converted to and from the list representation with ease, preferably without an explicit conversion step. In this way, code using VecTcl can seamlessly interface to code written in pure Tcl, like math::linearalgebra, which uses the same encoding, and to other packages supporting sequences of numbers. Value semantics also allows Tcl procs to extend the language, pass vectors back and forth as first class objects, and leave memory management to the Tcl interpreter. It should be noted, that VecTcl does NOT use the list representation at the C level, nor is hidden information carried along that breaks the value semantics.
  3. Generality. There should be no arbitrary limitation on the number of dimensions or the size of the objects. The vector engine should not be limited to 3D vectors and support higher-rank tensors both with syntax and in the backend as well as matrices and vectors.
  4. No external dependencies. Besides what is required to compile Tcl itself, no external libraries should be required to compile nor run the code. This means that the code must be written in pure C, use TEA and stubs, and generated code must be included prebuilt within the package. A few high-quality BSD compatible libraries have been incorporated into the project. Faster alternatives for these libraries exist, but have been ruled out due to incompatible licenses or codesize. Facultative dependency on these external libraries would be acceptable as a compile-time choice.
  5. Performance. In order to justify a C level extension, both memory footprint and execution speed of the computation should be kept as efficient as possible, and in any case better than what could be achieved with a Tcl level implementation.

It is clear, that these objectives compete, and so a certain compromise must be achieved. For example, performance could be improved by adding external dependencies, or usage could be simplified by loss of generality (e.g. restricting the values to two-dimensional matrices instead of N-rank tensors). The following sections give an overview over the compromise sought, what is achieved and what is planned or desirable.

Read more about