{"title": "An Object-Oriented Framework for the Simulation of Neural Nets", "book": "Advances in Neural Information Processing Systems", "page_first": 797, "page_last": 804, "abstract": null, "full_text": "An Object-Oriented Framework for the \n\nSimulation of Neural Nets \n\nA. Linden \n\nTh. Sudbrak \n\nCh. Tietz \n\nF. Weber \n\nGerman National Research Center for Computer Science \n\nD-5205 Sankt Augustin 1, Germany \n\nAbstract \n\nThe field of software simulators for neural networks has been ex(cid:173)\npanding very rapidly in the last years but their importance is still \nbeing underestimated. They must provide increasing levels of as(cid:173)\nsistance for the design, simulation and analysis of neural networks. \nWith our object-oriented framework (SESAME) we intend to show \nthat very high degrees of transparency, manageability and flexibil(cid:173)\nity for complex experiments can be obtained. SESAME's basic de(cid:173)\nsign philosophy is inspired by the natural way in which researchers \nexplain their computational models. Experiments are performed \nwith networks of building blocks, which can be extended very eas(cid:173)\nily. Mechanisms have been integrated to facilitate the construction \nand analysis of very complex architectures. Among these mech(cid:173)\nanisms are t.he automatic configuration of building blocks for an \nexperiment and multiple inheritance at run-time. \n\n1 \n\nIntroduction \n\nIn recent years a lot of work has been put into the development of simulation \nsystems for neural networks [1, 2, 3, 4, 5, 6, 7, 9, 10, 11, 12]. Unfortunately their \nimportance has been largely underestimated. In future, software environments will \nprovide increasing It-vels of assistance for the design, simulation and analysis of \nneural networks as well as for other pattern and signal processing architectures. Yet \nlarge improvements are still necessary in order to fulfill the growing demands of the \nresearch community. Despite the existence of at least 100 software simulators, only \nvery few of them can deal with, e. g. multiple learning paradigms and applications, \n\n797 \n\n\f798 \n\nLinden, Sudbrak, Tietz, and Weber \n\nvery large experiments. \n\nIn this paper we describe an object oriented framework for the simulation of neural \nnetworks and try to illustrate its flexibility, transparency and extendability. The \nprototype called SESAME has been implemented using C++ (on UNIX workstations \nrunning X-Windows) and currently consists of about 39.000 lines of code, imple(cid:173)\nmenting over 80 classes for neural network algorithms, pattern handling, graphical \noutput and other utilities. \n\n2 Philosophy of Design \n\nThe main objective of SESAME is to allow for arbitrary combinations of different \nlearning and pattern processing paradigms (e. g. supervised, unsupervised, self(cid:173)\nsupervised or reinforcement learning) and different application domains (e. g. pat(cid:173)\ntern recognition, vision, speech or control). To some degree the design of SESAME \nhas been based on the observation that many researchers explain their neural in(cid:173)\nformation processing systems (NIPS) with block-diagrams. Such a block diagram \nconsists of a group of primitive elements (building blocks). Each building block has \ninputs and outputs and a functional relationship between them. Connections de(cid:173)\nscribe the flow of data between the building blocks. Scripts related to the building \nblocks specify the flow of control. Complex NIPS are constructed from a library \nof building blocks (possibly themselves whole NIPS), which are interconnected via \nuniform communication links. \n\n3 SESAME Design and Features \n\nAll building blocks share a list of common components. They all have insites and \noutsites that build the endpoints of communication links. Datafields contain the \ndata (e. g. weight matrices or activation vectors) which is sent over the links. Ac(cid:173)\ntion functions process input from the insites, update the internal state and compute \nappropriate outputs, e. g. performing weight updates and propagating activation or \nerror vectors. Command functions provide a uniform user interface for all build(cid:173)\ning blocks. Scripts control the execution of action or command functions or other \nscript.s. They may contain conditional statements and loops as control structures. \nFurthermore a symbol table allows run-time access to parameters of the building \nhlock as learning rat.E's, sizes, data ranges etc. Many other internal data struc(cid:173)\ntures and routines are provided for the administration and maintainance of building \nblocks. \n\nThe description of an experiment may be divided into the functional description \nof the building blocks (which can be done either in C++ or in the high-level de(cid:173)\nscription language, see below), the connection topology of the building blocks used, \nthe cont.rol flow defined by scripts and a set of parameters for each of the building \nblocks. \n\n\fAn Object-Oriented Framework for the Simulation of Neural Nets \n\n799 \n\nDesign Highlights \n\n3.1 User Interface \n\nThe user interface is text oriented and may be used interactively as well as script \ndriven. This implies that any command that the user may choose interactively can \nalso be used in a command file that is called non-interactively. This allows the easy \nadaption of arbitrary user interface structures from a primitive batch interface for \nlarge offline simulatiors to a fancy graphical user interface for online experiments. \n\nAnother consequence is that experiments are specified in the same command lan(cid:173)\nguage that is used for the user interface. The user may thus easily switch from \ndescription files from previously saved experiments to the interactive manipulation \nof already loaded ones. Since the complete structure of an experiment is accessible \nat runtime, this not only means manipulation of parameters but also includes any \nimaginable modification of the experiment topology. The experienced user can, for \nexample, include new building blocks for experiment observation or statistical eval(cid:173)\nuation and connect them to any point of the communication structure. Deletion of \nbuilding blocks is possible, as well as modifying control scripts. The complete state \nof the experiment (i. e. the current values of all relevant data) can be saved for later \nexperiments. \n\n3.2 Hierarchies \n\nIn SESAME we distinguish two kinds of building blocks: terminal and non-terminal \nblocks. Non-terminal building blocks are used to structure a complex experiment \ninto hierarchies of abstract building blocks containing substructures of an experi(cid:173)\nment that may themselves contain hierarchies of substructures. Terminal building \nblocks provide the data structures and primitive functions that are used in scripts \n(of non-terminal blocks) to compose the network algorithms. A non-terminal build(cid:173)\ning block hides its internal structure and provides abstract sites and scripts as an \ninterface to its internals. Therefore it appears as a terminal building block to the \noutside and may be used as such for the construction of an experiment. This con(cid:173)\nstruction is equivalent. to the building of a single non-terminal building block (the \nExperiment) that encloses the complete experiment structure. \n\n3.3 Construction of New Building Blocks \n\nThe functionality of SESAME can be extended using two different approaches. New \nterminal building blocks can be programmed deriving from existing C++ classes or \nnew non-terminal building blocks may be assembled by using previously defined \nbuilding blocks: \n\n3.3.1 Programming New Terminal Building Blocks \n\nTerminal building blocks can be designed by derivation from already existing C++ \nclasses. The complete administration structure and possible predefined properties \nare inherited from the parent classes. In order to add new properties -\ne. g. new \na set of basic opera(cid:173)\naction functions, symbols, datafields, insites or outsites -\ntions is being provided by the framework. One should note that new algorithms \n\n\f800 \n\nLinden, Sudbrak, Tietz, and Weber \n\nand structures can be added to a class without any changes to the framework of \nSESAME. \n\n3.3.2 Composing New Non-Terminal Building Blocks \n\nNon-terminal building blocks can be combined from libraries of already designed \nterminal or non-terminal blocks. See for an example fig. ??, where a set of building \nblocks build a multilayer net which can be collapsed into one building block and \nreused in other contexts. Here insites and outsites define an interface between \nbuilding blocks on adjacent levels of the experiment hierarchy. The flow of data \ninside the new building block is controlled by scripts that call action functions or \nscripts of its components. Such an abstract building block may be saved in a library \nfor reuse. Even whole experiments can be collapsed to one building block leaving \na lot of possibilities for the experimenter to cope with very large and complicated \nexperiments. \n\n3.3.3 Deriving New Non-Terminal Building Blocks \n\nA powerful mechanism for organizing very complex experiments and allowing high \ndegrees of flexibility and reuse is offered by the concept of inheritance. The basic \nmechanism executes the description of the parent building block and thereafter \nthe description of the refinements for the derived block. All this may be done \ninteractively, thus additional refinements can be added at runtime. Even the set of \nformal parameters of a block may be inherited and/or refined. Multiple inheritance \nis also possible. \n\nFor an example consider a general function approximator which may be used at \nmany points in a more complex architecture. It can be implemented as an abstract \nbase building block, only supplying basic structure as input and output and basic \noperations as ((propagate input\" and ((train\" . Derivations of it then implement the \nalgorithm and structure actually used. Statistical routines, visualization facilities, \npattern handling and other utilities can be added as further specializations to a \nbasic function approximator. \n\n3.3.4 Parameters and Generic Building Blocks \n\nA building block may also define formal parameters that allow the user to con(cid:173)\nfigure it at the time of its instantiation or inclusion into some other non-terminal \nbuilding block. Thus non-terminal building blocks can be generic. They may be \nparameterized with types for interior building blocks, names of scripts etc. With \nthis mechanism a multilayer net can be created with an arbitrary type of node or \nweight layers. \n\n3.4 Autoconfiguration \n\nWhen a user defines an experiment, only parameters that are really important \nmust be specified. Redundant parameters, that depend on other paremeters of other \nbuilding blocks, can often be determined automatically. In SESAME this is done via \na constraint satisfaction process. Not only does this mechanism avoid specification \nof redundant information and check experiment parameters for consistency, but it \n\n\fAn Object-Oriented Framework for the Simulation of Neural Nets \n\n801 \n\nalso enables the construction of generic structures. Communication links between \noutsites and insites of building blocks check data for matching types. Building blocks \nimpose additional constraints on the data formats of their own sites. Constraints are \nformed upon information about the base types, dimensions, sizes and ranges of the \ndata sent between the sites. The primary source of information are the parameters \ngiven to the building blocks at the time of their instantiation. After building the \nwhole experiment, a propagation mechanism iteratively tries to complete missing \ninformation in order to satisfy all constraints. Thus information which is determined \nin one building block of the experiment may spread all over the experiment topology. \nAs an example one can think of a building block which loads patterns from a \nfile. The dimensionality of these patterns may be used automatically to configure \nbuilding blocks holding weight layers for a multilayer network. \n\nThis autoconfiguration can be considered as finding the unique solution of set of \nequations where three cases may occur: inconsistency (contradiction between two \ninformation sources at one site), deadlock (insufficient information for a site) or suc(cid:173)\ncess (unique solution). Inconsistencies are a proof of an erroneous design. Deadlocks \nindicate that the user has missed something. \n\n3.5 Experiment Observation \n\nGraphical output, file I/O or statistical analysis are usually not performed within \nthe normal building blocks which comprise the network algorithms. These features \nare built into specialized utility building blocks that can be integrated at any point \nof the experiment topology, even during experiment runs. \n\n4 Classes of Building Blocks \n\nSESAME supports a rich taxonomy of building blocks for experiment construction: \n\nFor neural networks one can use building blocks for complete node and weight layers \nto construct multilayer networks. This granulation was chosen to allow for a more \nefficient way of computation than with building blocks that contain single neurons \nonly. This level of abstraction still captures enough flexibility for many paradigms \n,of NIPS. However, terminal building blocks for complete classes of neural nets are \nalso provided if efficiency is first demand. \n\nMathematical building blocks perform arithmetic, trigonometric or more general \nmathematical transformations, as scaling and normalization. Building blocks for \ncoding provide functionality to encode or decode patterns. \n\nUtility building blocks provide access to the filesystem, where not only input or \noutput files can be dealt with but also other UNIX processes by means of pipes. \nOthers simply store structured or unstructured patterns to make them randomly \naccessible. \n\nGraphical building blocks can be used to display any kind of data no matter if \nweight matrices, activation or error vectors are involved. This is a consequence of \nthe abstract view of combining building blocks with different functionality but a \nuniform data interface. There are special building blocks for analysis which allow \nfor clustering, averaging, error analysis, plotting and other statistical evaluations. \n\n\f802 \n\nLinden, Sudbrak, Tietz, and Weber \n\nFinally simulations (cart pole, robot-arms etc.) can also be incorporated into build(cid:173)\ning blocks. Real-world applications or other software packages can be accessed via \nspecialized interface blocks. \n\n5 Examples \n\nSome illustrative examples for experiments can be found in [?] and many additional \nand more complex examples in the SESAME documentation. The full documenta(cid:173)\ntion as well as the software are available via ftp (see below). \n\nHere we sketch only briefly, how paradigms and applications from different domains \ncan be easily glued together as a natural consequence of the design of SESAME. \nFigure?? shows part of an experiment in which a robot arm is controlled via \na modified Kohonen feature map and a potential field path planner. The three \nbuilding blocks, workspace, map and planner form the main part of the experiment. \nWorkspace contains the simulation for the controlled robot arm and its graphical \ndisplay and map contains the feature map that is used to transform the map coordi(cid:173)\nnates proposed by planner to robot arm configurations. The map has been trained \nin another experiment to map the configuration space of the robot arm and the \nplanner may have stored the positions of obstacles with respect to the map coordi(cid:173)\nnates in still another experiment. The configuration and obstacle map have been \nsaved as the results of the earlier experiments and are reused here. The map was \ntaken from a library that contains different flavors of feature maps in form of non(cid:173)\nterminal building blocks and hides the details of its complicated inner structure. \nThe Views help to visualize the experiment and the Buffers are used to provide \nstart values for the experiment runs. A Subtractor is shown that generates control \ninputs for the workspace by simply performing vector subtraction on subsequently \nproposed state vectors for the robot arm simulation. \n\n6 Epilogue \n\nWe designed an object-oriented neural network simulator to cope with the increas(cid:173)\ning demands imposed by the current lines of research. Our implementation offers \na high degree of flexibility for the experimental setup. Building blocks may be \ncombined to build complex experiments in short development cycles. The simula(cid:173)\ntor framework provides mechanisms to detect errors in the experiment setup and \nto provide parameters for generic subexperiments. A prototype was built, that is \nin use as our main research tool for neural network experiments and is constantly \nrefined. Future developments are still necessary, e. g. to provide a graphical in(cid:173)\nterface and more elegant mechanisms for the reuse of predefined building blocks. \nFurther research issues are the parallelization of SESAME and the compilation of \nexperiment parts to optimize their performance. \n\nThe software and its preliminary documentation can be obtained via ftp at \n:ftp.gmd.de in the directory gmd/as/sesame . Unfortunately we cannot provide \nprofessional support at this moment. \n\nAcknowledgments go to the numerous programmers and users of SESAME for all \nt.he work, valuable discussions and hints. \n\n\fAn Object-Oriented Framework for the Simulation of Neural Nets \n\n803 \n\nReferences \n\n[1] B. Angeniol and P. '\"rreleaven. The PYGMALION neural network programming \nenvironment. In R. Eckmiller, editor, Advanced Neural Computers, pages 167 \n- 175, Amsterdam, 1990. Elsevier Science Publishers B. V. (North-Holland). \n[2] N. Goddard, K. Lynne, T. Mintz, and 1. Bukys. Rochester connectionist simu(cid:173)\nlator. Technical Report TR-233 (revised), Computer Science Dept, University \nof Rochester, 1989. \n\n[3] G . 1. Heileman, H. K. Brown, and Georgiopoulos. Simulation of artificial neural \nnetwork models using an object-oriented software paradigm. In Proceedings of \nthe International Joint Conference on Neural Networks, pages 11-133 - 11-136, \nWashington, DC, 1990. \n\n[4] NeuralWare Inc. Neuralworks professional ii user manual. 1989. \n[5] T. T. Kraft. AN Spec tutorial workbook. San Diego, CA, 1990. \n[6] T. Lange, J .B. Hodges, M. Fuenmayor, and L. Belyaev. Descartes: Develop(cid:173)\nment environment for simulating hybrid connectionist architectures. In Pro(cid:173)\nceedings of the Eleventh A nnual Conference of the Cognitive Science Society, \nAnn Arbor, MI, August 1989, 1989. \n\n[7] A. Linden and C. Tietz. Combining mUltiple neural network paradigms and ap(cid:173)\n\nplications using SESAME. In Proceedings of the Internation Joint Conference \non Neural Networks IJCNN - Baltimore. IEEE, 1992. \n\n[8] Y. Miyata. A user's guide to Sun Net version 5.6 - a tool for constructing, \n\nrunning, and looking into a PDP network. 1990. \n\n[9] J. M. J. Murre and S. E. Kleynenberg. The MetaNet network environment \n\nfor the development of modular neural networks. In Proceedings of the In(cid:173)\nternational Neural Network Conference, Paris, 1990, pages 717 - 720. IEEE, \n1990. \n\n[10] M.A. Wilson, S.B. Upinder, J.D. Uhley, and J.M. Bower. GENESIS: A system \nfor simulating neural networks. In David S. Touretzky, editor, Advances in \nNeural Information Processing Systems I, pages 485-492. Morgan Kaufmann, \n1988. Collected papers of the IEEE Conference on Neural Information Pro(cid:173)\ncessing Systems - Natural and Synthetic, Denver, CO, November 1988. \n\n[11] A. ZeIl, N. Mache, T. Sommer, and T. Korb. Recent developments of the snns \nneural network simulator. In SPIE Conference on Applications of Artificial \nNeural Networks. Universit\"at Stuttgart, April 1991. \n\n\f804 \n\nLinden, Sudbrak, Tietz, and Weber \n\n............ \n\n1 \ntet \n: : \n\nuu.a \n\n0 . . . . . . \n\n.. : . \nf: ' \n\n: : ' \n\nB ..... \nall . . . :: \n\n.PN .... \n1IIcI \u2022\u2022 \n\nBl'Lleu \nIIWape. \n\n.:;.' \n\n: : . . \n\nNt \n\n....... Nt \n\n.. \n\nI \n\n. ~; \n':;.;. ... \n---1 \n\n\u2022 Nt \n\n\"' Sea_Is \n\nd.,.1s \n\nI \n\n.. \n\nFigure 1: Integration of several terminal building blocks into a non-terminal building \nblock with the Backpropagation example. \n\nL~ I\"\"\"\" \n\nSUb.,...,...~b \ninJliD2 \nT \n~ .\"IIB1a I .weOu! \n\nI ooatrolIa I--\n\n.... \n\nloaIID I \n,leldPlaa .... \n\nt*!MapO\" \n\n,..a ... \n\n.atPo.Out j ' I ctP .. Ja \n\nL \n\nTwoA .... VIcw: : \n\nwert...-\n\nI 10lIIla \nt \n\nI8fennal \n\nDotIbieMap \n\n\u2022\u2022 p \n\n\u2022\u2022 rr., \n\n,., \n\now \n\nia2 \n\nl~rOu! -\n\nI iDdea \n\now \n.alrcr \n.lIIr1aNlr \n\nrcul&!u_vj4,9, \n\n~ \noIIltm.p p; ... \n\nW.I wID .... \n\nPlal.Vlew \n\nFigure 2: Robot arm control with a hybrid controller \n\n\f", "award": [], "sourceid": 708, "authors": [{"given_name": "A.", "family_name": "Linden", "institution": null}, {"given_name": "Th.", "family_name": "Sudbrak", "institution": null}, {"given_name": "Ch.", "family_name": "Tietz", "institution": null}, {"given_name": "F.", "family_name": "Weber", "institution": null}]}