| | |
Sifting through scores of old, badly maintained code of tools for scientific computing showed several recurring themes and topics from the different fields of mathematics presented in Chapter 4. However, only very few of the implementations seemed to have any regard for reusability. At times there did not seem to be a discernible theme of purpose at all. Turning to what little documentation was available, it was found to be akin to the black box of a crashed air plane, horribly mangled and beyond use. Since the greater use of the code was still available, it was possible to reverse engineer the intent of the local code, but at a much greater expense than necessary. The bad state of the source code and the great effort required to divine its intended purpose cannot be attributed to a single factor. The implementations were designed with the imperative as well as object-oriented paradigms in mind. And while they were realized with considerable forethought as well as skill in programming, they also passed through the hands of several different programmers of very diverse levels of awareness of the abstractions used in the initial writing as well as skill. Thus the initially object-oriented components, with their hierarchy and data encapsulation were soon subverted in order to make access easier for purely imperative constructs. This trend seems to have been accelerated by bursts of sloppiness due to haste such as resulting due to approaching deadlines, leaving obviously deeply flawed constructions behind. This is of course nothing, which anyone would want to document, if it is done consciously, while the interesting implications do not come to mind, if it is done unconsciously. The resulting monstrous heap of code is an unwieldy nightmare to maintain and extend. This situation was confounded by a lack of unit testing infrastructure which made diagnostics virtually impossible on a manageable scale.
Naturally, the prevention of such a dreadful deterioration of new projects in the same fashion was among the main questions resulting from this encounter. An answer to this may be found in the nature of the object-oriented paradigm and its facilities for code reuse, which do not easily allow for non-intrusive extensions after the initial design. As the initial design cannot encompass all subsequent use cases and scenarios, such extensions seem unavoidable. Thus intrusive changes are unavoidable, which may, however, change the behaviour of the entire object, if not performed with a modicum of diligence. This scenario also makes it much more appealing to simply attempt to circumvent the now bothersome mechanisms of clean object-oriented designs, instead to improving it; especially, when the initial design may no longer be clear.
Therefore, key components, whose concepts have been found strewn throughout the legacy code bases, have been identified and their mathematical descriptions and definitions isolated, as shown in Chapter 4. Using these mathematical concepts options for implementation have been sought and explored relying on the generic programming paradigm. The rational behind this is that mathematical concepts are quite robust to the evolution of methodology as long as they are well defined. Furthermore, the generic implementations offer much less incentive to be subverted to be extended, since extensions should be possible unintrusively. Thus it should be much more common for code to be simply phased out, as it is replaced by more adequate implementations. Where the result of the extraction of basic mathematical concepts found useful for scientific computing has been described in Chapter 4, their mapping to the realm of digital computers is described in the the following. As the compilation of definitions was a theoretical contribution, the description of example realizations here is of a practical nature. It puts well known data structures in their contexts and supplies additions, where needed.
Sets are an essential building block used in computing, since the memory used to store values in digital computing constitutes a set. Each of the memory cells within the whole are distinguishable from one another and form a discrete topological space (Definition 29). The discrete nature of a digital computer’s memory not only forces the topology to be Hausdorff (Definition 33), but also results in the fact that every mapping (Definition 20) among memory cells is continuous (Definition 30). The distinct existence of memory cells would be incomplete, if they could not each store values. A short examination reveals that this structure matches the definition of a fiber bundle (Definition 40) with the memory as the base space and their contents as the respective fibers. The management and partitioning (Definition 2) of a system’s memory is commonly a central task of an operating system’s kernel. It is facilitated by the use of addresses, which identify all of the memory locations, which is easily recognized as the use of an atlas (Definition 36), effectively identifying the structure as a manifold (Definition 35). The atlas may be comprised by a single chart, but may also be more complicated as in the case of paged virtual memory [101] for instance. While it is common for this structure to be ignored, or go unexplored as unnecessarily complex, it still is present even in these basic primitive layers of machines. Any higher abstractions dealing with topological spaces or manifolds are essentially mappings from the intended structures to this low level manifold. Thus special care of encoding their structure in a fashion suitable to a representation in the lowest levels of the used machines has to be taken. It furthermore illustrates the worth of having definitions available, with which to describe encountered structures.
Additional components were added to an already existing generic scientific simulation environment (GSSE) [57 ][28][102] to enable an efficient realization of topological space concepts given in Chapter 4. The environment provides a variety of compile time and run time interfaces to arbitrary-dimensional topological spaces, e.g., sets, graphs, implicit and explicit grid and mesh structures.
| | |