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:
- Ease of use
- Interoperability
- Generality
- No external dependencies
- Performance
These terms are interpreted within VecTcl in the following sense:
- 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.
- 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.
- 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.
- 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.
- 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