In general, system matrix notation (SMN) is a mathematical formalism with which we can represent and animate general systems and general massively parallel computational processes.
It has potentially profound theoretical implications but here we consider it within an IT context. SMN is a computational process that produces a systemic cyberspace in the sense that virtual systems exist and interact within a virtual reality. Thereby creating complex parallel processes that function as various information technologies (software). You can download the SMN engine here plus there are earlier prototypes available, which provide examples of simple uses of SMN, for example to create a simple particle simulator, drawing program, calculator, cellular automata, etc.
This approach is still in an early stage of development but there are working prototypes of the core technology and many avenues for further development.
The SMN model represents the network of connectivity between systems, their interfaces and interactions and their responses to these interactions. By iterating the SMN algorithm the model simulates a virtual universe populated by systems that interact, experience each other and change over time.
When this approach is applied to the context of binary data and computational processes it can be used to create software systems and virtual interactive environments. SMN can serve as the core (kernel) of a program, an operating system, a control system or an embedded system.
The SMN algorithm is highly amenable to parallel processing and provides a mathematical science and engineering methodology for the integration of parallel processors, for massively parallel software development and for general system design and modelling.
Moore's law describes the exponential rate of increase of computational power in the computing industry. Although it has been exponential for many decades it is now reaching a plateau. The speed of the interactions between the components of a CPU partially depend on the distance between them, hence as the circuitry was minimised (and other technologies improved) the speed of the circuitry increased. The density and therefore complexity also increased.
However now we are approaching the quantum limit and the semi-conductor circuits cannot be made any smaller because beyond the quantum limit classical concepts do not have any meaning. Beyond the quantum limit a bit isn't either zero OR one, it is a quantum superposition of both states which dynamically evolves over time and can perform an exponential number of computations in parallel. For example, a 64 qbit quantum computer would effectively have 264 (approximately 18x1018 ) computational streams.
This will represent a vast leap in computing power and the quantum version of SMN (beyond the scope of this discussion, see here) may provide leads towards discovering a general purpose method of programming quantum computers.
But until quantum computers come along, the main way in which Moore's law is being maintained is by the move towards parallel processing. Rather than faster processors there is more processors. Hence multi-threaded software engineering is coming into focus as an important area of development.
One of the benefits of SMN in this context is that it provides a rigorous method for integrating the computational potential of a large number of processors and allows them to all interact with each other within a shared memory space. All of the thread-safety issues are seamlessly handled by SMN and no clashes can occur.
Hence SMN provides the basis for a mathematical science and engineering methodology for the integration of parallel processors, for massively parallel software development and for general system design and modelling.
To really understand what SMN is one also needs to understand in some way how SMN works, what SMN does and the ontological structure of SMN. Hence some of the following concepts will be better understood after studying the explanations at those links. However an overview can be grasped from this explanation – there is also a collection of brief comments that have been made about SMN and a general notice to software developers that is a few years old but still relevant.
The current SMN engine is coded in ANSI C and can be compiled for any platform. It operates as a general simulation engine that can integrate any set of binary data and functions into a complex dynamical system. However it is not very user-friendly in its current form – it is just a prototype to test the functionality and efficiency of the core technology.
Eventually, using this sort of approach, complex software systems can be created and further integrated into complex networks of systems, thus allowing us to create information technologies that were previously impossible due to their complexity.
SMN could allow complex systems of all kinds to be comprehended, designed, constructed, simulated, tested and analysed.
It could also make possible, relatively codeless-programming where the creator only needs to understand the system that they wish to create and know how to create a system model using a general modelling method. Rather than then having to translate that into computer code, the system model itself can be automatically translated into SMN and animated, thus creating the 'program' from the model alone, without any coding.
The individual system interaction and response functions still need to be coded, but as we develop a repository of useful basic systems these can be simply placed into the system model, hence the 'programmer' just uses a GUI to create a system model and define its attributes, and then runs it using SMN without any need for coding.
Furthermore, the model can dynamically change and the user of the system can observe and influence the process of change. Conventional software operates within the computational space (executable code processed by the CPU) which is totally separate from the user space (the space of programs, menu items, images and so on). Apart from limited configuration settings the user has virtually no knowledge of what is happening within the software, neither do they have any control over the details of what the software does.
However the SMN engine provides a virtual space between the computational and the user spaces. The virtual space is observable and customisable even whilst the model is running. The user can explore the inner workings of the system they are using and can optionally edit the model. The only parts that operate in the computational space are the engine itself and the behaviour of the atomic systems (their interaction, response and sysWrap functions). This makes the bulk of the application virtualware, which is observable and customisable even whilst the model is running. This is equivalent to the manner in which we can scientifically pry into the workings of our universe even whilst we are emergent from it and entirely embedded within it.
However there are also ways of controlling user access to parts of a system.
This approach represents a massive paradigm-shift in computing. Rather than think of computers as fast calculators or document processors - they are instead virtual universes within which we can intimately participate and they are populated by complex systems, with which we can interact.
For example, highly complex and intuitive, multi-media virtual environments can be created if we expand our thinking beyond the 'document' paradigm and re-imagine the whole situation in terms of a semiotic space within which there functions a complex system of interacting and dynamic items of information, which are interlinked in meaningful ways and with which people can dynamically participate and co-create.
An operating system can be developed more as a sophisticated portal into a space of virtual universes that is seamlessly interconnected via networks into a global systemic cyberspace with a myriad of virtual universes populated by innumerable complex systems.
This system theoretic software methodology can provide a coherent foundation for a wide range of new technologies that will help us create, comprehend and manage complex systems of all kinds.
The SMN engine is the software implementation of the SMN algorithm. When given a model it will animate it. It operates on raw binary data so it doesn't know or care what the systems are that it is animating, they are all just information-in-motion from its perspective. The model may represent any kind of system, but the engine knows nothing about what is encoded within the model. The engine simply processes binary data in the manner of the SMN algorithm.
It is only within the interaction and response functions that the data has a type and a meaning, perhaps as a character string or a bitmap image or an event or a function that does such-and-such.
In this sense the SMN engine is a high level virtual machine, an abstract virtual computer that produces a system theoretic cyberspace. SMN can also be implemented on-chip as an extension to conventional CPU's, thus resulting in a high-level CPU with a system theoretic cyberspace.
Although SMN may process vast models and thereby animate very complex systems, the engine itself is extremely compact. The core executable file is only 100 Kb and the amount of system resources used whilst the engine is running depends primarily on the complexity of the model, with the SMN engine itself requiring very little.
The current engine can use one of two multithreaded processing strategies - full or partial. Using full multithreading all models are animated in parallel on a system level granularity. Using partial multithreading all models are animated in parallel on a model level granularity. Full multithreading is slower but with multiple processors it allows for the animation of extremely large models at high iteration rates. Partial mutlithreading is faster and it is best suited for animating large numbers of models that are independent or weakly interacting. As a benchmark of the speed of the current SMN engine it was made to process 1000 models (using partial multithreading), each model simulated conserved fluid flow between two reservoirs. On a machine with a dual core 2GHz processor and using 260 threads it runs at 13.4 million model iterations per second (13.4 MHz).
That's about 26.8 million system events per second (because there is two systems in each model). Which means about 150 CPU cycles per system event.
These figures would change approximately linearly for machines with more processors and for models with more complexity.
Because sparse matrices and energy flow processing are used (see how SMN works), the computational complexity scales approximately linearly with the complexity of the model. This means that, for example, the current engine running on such a machine, if it was to run at 25 Hz; just enough to be smooth to the human eye, it could handle approximately 1.1 million simple systems, either in a single model or spread throughout multiple models.
However, when run with more processors these figures would scale linearly with the number of processors. Furthermore, when implemented on-chip rather than as a virtual machine it will run a lot faster and therefore be able to simulate more complex systems in real-time.
Regarding its theoretical limits, the current engine can process
264 (
18x1018
) different models in parallel and each model can contain 264
different systems. These figures increase exponentially when using
more bits for indexing. For example, if we use 256 bits the number is
approximately 1077 models and systems per model, which
gives more than enough cyber-space for now.
Users can add and remove models and systems without any comprehension of the underlying framework, they just give each model and each system within that model a unique identifier. Using these identifiers a system can declare that it interacts with another system and all the low-level interconnections are handled by the engine.
The parallel models are like parallel virtual universes within which virtual systems can interact either directly with each other via the SMN algorithm, or across virtual universes or with the outside world via wormhole-like sysWrap functions.
At present the SMN methodology has two interfaces, firstly a C programming API via which system models can be constructed and secondly a high level modelling interface that uses OWL (Web Ontology Language) which is an RDF/XML based markup language. Hence we can use semantic/ontology engineering interfaces such as Protégé, Neon-Toolkit, OntoStudio, etc to create system models.
Further interfaces can be developed that use UML, XTM, C++, Java, Matlab,... - any structured context that is capable of representing/defining a system model. Hence many interfaces can be used.
System Development Using SMN and OWL
In metaphysics, an ontology is the set of all entities that we believe to exist and the set of all relations that are believed to exist between these entities – it defines the scope of that which is believed to be real.
In the context of semantic technology an ontology defines all entities and relations that exist within some conceptual domain. When we use OWL to define system models the conceptual domain is virtual systems and their interactions within a virtual universe. The ontology defines the scope of what is possible within the virtual universe.
For a good introduction to OWL (and in particular Protégé – OWL) see this tutorial, also see the official documentation.
Once the class hierarchy and system hierarchy of the ontology have been constructed, the relations between systems have been defined and the atomic systems instantiated as individuals, this is saved as an OWL file, which is then loaded by the SMN engine and translated into a system model, which can be simulated by the engine.
For details on how to create system models in OWL, which can be animated by SMN, see this introductory tutorial.
For an example of an ontology that utilises SMN, see the perception, cognition and communication (PCC) ontology, which provides a universe of discourse within which we can make expressions about empirical phenomena, such as what we believe to exist, what we experience, what we think and what we express/communicate. This ontology aims to assist us to explicitly and accurately describe and reason with conceptual networks that are connected with expressions (e.g. references to articles), empirical data (e.g. in a data file) and simulations (using SMN systems).
Native SMN
SMN creates computational processes that function as general software and will eventually provide its own interface entirely animated by SMN. This will provide a system design suite with which people can create, analyse and deploy system oriented software. This would also be a general system simulator that can be used to model, design and analyse complex dynamical systems.
The only traditional 'program' will be the SMN engine, which processes model data. The GUI and overall interface will be created in virtualware, as an SMN model that implements a virtual system, which provides the user with intimate access to the virtual reality potential provided by the engine.
This can be added to with further models that act as plugins that provide specialised functionality tailored for different activities such as software development, system modelling and analysis, mathematical computation, semantic engineering, scientific simulation, control system development, multimedia and web design, virtual reality game development and so on.
This is a diverse and multi-faceted field of creative potential, the core of which will be explored as an open-source project. Commercial development and application is encouraged and will be integral, however the core will be community developed and maintained in a open, transparent and diverse manner.
www.Anandavala.info 14th Sept 2008