Central docusfile regarding computer algebra.
General principles
The computeralgebra systems are taken as "programming languages with
associated libraries". Thus the underlying languages are taken seriously(!), and they constitute two different abstraction levels:

The "basic level" is the "Lisp level", that is, CLisp with Maxima:

The role model for all "data types" here is set theory.

For example, a graph is a pair "[V,E]" of vertexset V and a set E of 2element subsets of the vertexset.

Faithful to the settheoretic approach, a "vertex" can be anything.

For a "general graph" we use a map from the set of edgelabels to the 1 or 2element subsets.

Similarly, a clauseset is a set of clauses, etc.

However, the fundamental objects now are lists:

In set theory the fundamental object is a set, an unordered structure, since the mathematical world is eternal, objects are not created, but exist.

Computation on the other hand fundamentally relies on order, so the most basic object is accordingly the list.

"Objects stand for themselves":

As in set theory, a list can represent many things, and interpretations must be added to give it meaning.

So for example "[{},{}]" can be

the graph with no vertices,

the hypergraph with no vertices and no hyperedges,

as well as the formal clauseset with no variables and no clauses.

Objects are not adorned to fix their meaning.

The language is untyped, and this is (taken for this level(!)) "a feature, not a bug".

No type checking of any kind is performed, but the algorithms are formulated as "pure generic algorithms" based on established conventions how to access the data.

Thus the algorithms are open for more general applications than perhaps originally anticipated.

For defining the concepts, and for error checking, predicates are provided which check whether objects are wellformed according to the notion of a "graph", a "clauseset" etc.; but these predicates are not used for programming.

"Flow with Lisp", that is, put things in a natural way into lists, and neither worry about efficiency nor about abstraction and concepthierarchies.

No polymorphism is employed, but concrete representations (exploiting the generality of lists and terms) together with conversion functions.

A central point here is that abstraction must come later.

First we make concrete experiences with the real multiplicity of concrete types.

Abstraction is then added at the Aldor and C++ level.

The intention of this level is that of quick and elegant programming, for prototyping and experimentation.

It shall provide the specificational basis for the whole library.

No simulations of programming concepts which where not anticipated with Lisp.

The "extended level" is the "Aldor level", that is, Aldor with Axiom:

Aldor supports dependent types and concept hierarchies, and so here now abstraction is a central issue, with proper concept hierarchies and strict typing.

What still is abstracted away, compared to the "full level", are finegrained algorithmic choices and especially considerations regarding memory management and construction/destruction of objects.

It seems that most development will happen at the basic level (the Maxima/Lisp level) or at the full level, while the Axiom/Aldor level is about planning, formulating and prototyping abstraction.

For example, at the Maxima/Lisp level we develop a systematic and finegrained, but nonabstract account of all graph and hypergraph concepts, and a good selection on algorithms operating with these concepts.

After seeing this picture (for the first time!), we look at common principles, common methods, common interfaces.

That is, the multitude of concrete concepts is organised into a network of abstract concepts.

Currently we are in the phase of building up the basic level, and thus work at the Axiom/Aldor level is slowgoing.

The third level, the C++ level which is considered as the "full level", is no longer in the realm of computer algebra, and here in principal the full spectrum can be expressed, from hardware access to abstract concept hierarchies:

Especially algorithms can be fully finetuned.

And construction/destruction of objects can be fully controlled.

So, especially for SAT algorithms the general plan is to

first develop them at the simple Lisplevel,

then to develop the fundamental abstractions at the Aldorlevel,

and finally to explore all possibilities at the C++ level.
However, development can also start at the C++ level, and mimic these steps by first starting with the "C core part" of C++, and then adding abstraction and refinements.

The usage of Sage is restricted to provide interfaces between the different systems.
The underlying mathematical concepts are the same for all three levels, but their realisations might differ considerably in the three levels.
Usage
Tutorials
Definition in file general.hpp.