This section gives some technical details on the design of the program and serves as a guide to the source code. The reader who is primarily interested in using the program just as an application may skip this section in a first reading. After a general overview of the system I discuss two technical points concerning threads and dynamic loading, where a few explanations might be useful to understand the source code.
A structural overview for gTybalt is shown in the following figure:
gTybalt consists of three parts, labelled gTybalt-bin, gTybalt-dictionary and gTybalt-lib, which ensure communication between the different modules on which gTybalt is based. The first part, gTybalt-bin is either called from TeXmacs (in TeXmacs-mode) or directly from the shell (when issuing the command “gtybalt” from a shell) and implements an event loop. This program reads input from the keyboard, sends the commands to the C++ interpreter CINT for execution and directs the output either to TeXmacs or to a text window.
The program CINT interprets the commands. For this purpose it uses a library called gTybalt-dictionary, which can be thought of as a look-up table where to find the actual implementations of the encountered function calls. The source code for this library is generated automatically during the build phase of gTybalt. A file “LinkDef.h” specifies which functions and classes to include into this library. The library is then generated from the header files for these functions and classes. The CINT interpreter is not 100% standard C++ compatible and there are certain constructs, which cannot be processed by CINT. Therefore the header files for the GiNaC-library are first copied to a temporary directory and then processed by a perl script, which comments out any parts which cannot be fed into CINT.
Finally, the library gTybalt-lib is an ordinary library, defining gTybalt-specific functions like print, factorpoly or intnum. It depends in turn on other libraries, like Eqascii, GSL or NTL, which are however not visible in the interactive interface.
When plotting a function, it is desirable to have the window with the plot appearing on the screen, but at the same time still be able to work in the main window of gTybalt. Since there are now two possible actions which the user can take (e.g. typing new commands in the main window and modifying the plot inside the window with the plot) this is implemented using different threads. When starting gTybalt, the program will create a separate thread, which waits on a condition that a function should be plotted. When a plotting command is issued, CINT invokes a function, which just prepares some variables for the plot, signals that there is something to be plotted and then returns. Therefore after the return of this function the user can issue new commands in the main window of gTybalt. The thread waiting on the condition for plotting a function will wake up, plot the function and provide an event handler for events concerning the window with the plot. Therefore the user can now take actions in both the main window for gTybalt and the window with the plot. Once the window with the plot is cleared (by choosing from the menubar of the plot “File -> Quit ROOT” ) the thread for plots will fall into sleep again and wait till another plotting command is issued. Thread safety is guarenteed by copying the relevant expressions for the function to be plotted to global variables and by the reference counting mechanism of GiNaC: The expression to be plotted will be pointed at by at least one (global) variable, therefore it will not be modified. While a plot is displayed on the screen, any command to plot another function will be ignored. The user must first clear the window with the plot.
The default behaviour for numerical evaluation of a function uses the arbitrary precision arithmetic provided by the CLN library. For Monte Carlo integration, where a function needs to be evaluated many times, this is quite slow and therefore inefficient. It is also not needed, since statistical errors and not rounding errors tend to dominate the error of the final result. Therefore a different approach has been implemented for the numerical Monte Carlo integration: The function to be integrated is first written as C code to a file, this file is then compiled with a standard C compiler and the resulting executable is loaded dynamically (e.g. as a “plug-in”) into the memory space of gTybalt and the Monte Carlo integration routine uses this compiled C function for the evaluations.