Coxeter
Coxeter
Although Coxeter is not blessed with a programming language, it is not difficult in principle to extend the program, in order to carry out specific computations which are not already built-in, at least for users who are knowledgeable in C++. This is done by editing the special.cpp file, which is provided precisely for this usage.
The easiest way is to simply edit the special_f function, which currently just prints out "not implemented". After recompiling, the contents of the function will be executed on entering special.
But it is almost as easy to add new command names to the program : it suffices to edit the addSpecialCommands function, and to add one line for each new command name, modelled on the one defining the special command. Then one has to declare and define the function associated to the new command, and recompile (just say make). Of course, I'm assuming here that the code files are installed in your home directory; this kind of usage of the program should be confined to a private copy.
Unfortunately here I have to make an embarassing confession: although a number of useful functions are readily available (see in particular all the member functions of the CoxGroup class, defined in coxgroup.h), the fact that the program is not really clean C++, and in particular does not use C++-style i/o, nor the various STL containers, makes it much more difficult than it should have been to extend the program in good style. The reason for this is that this project has also been my learning ground for C++, and some things I just learned too late to consider using them for this release --- for instance, I discovered only much later that my List template is essentially equivalent to the STL's vector, and the same for a number of other containers and algorithms. What makes me wary of attempting the switch right now is that I have been burned in the early stages by the slowness of the system new in certain circumstances (for instance the construction of large minimal root tables was bringing the program almost to a halt); this has led me to take the memory allocation in my own hands, and I want to make sure that I am capable of using a non-standard allocator for the STL classes if need arises. A lot of work to do here!