![]() | ![]() | |
IBM home | Products & services | Support & downloads | My account |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
|
![]() |
||||
![]() |
Is Schrager's Cat Object-Oriented? | ![]() |
![]() ![]() ![]() |
![]() |
![]() | ||||
![]() |
![]() |
Why Natural Scientists Should Care About Object-Oriented Technology
Adolfo M. Nemirovsky
I. Why Object-Oriented?
Natural scientists model and simulate natural phenomena. Computers simulate "real" (e.g., balancing a checkbook, mimicking the behavior of a physical system,...) and "imaginary" (e.g., games) worlds. Rapid advances in hardware and software are making possible the treatment of interesting and complex systems (e.g., turbulent flows, critical dynamics, lattice quantum chromodynamics, weather prediction, cellular metabolism, social phenomena,...). Simula, a language that pioneered object-oriented technology was specially conceived for simulations. Hence, it is not surprising that object-oriented programming may make simulation and visualization of complex phenomena easier than procedural techniques (e.g., Fortran). For fully exploring models of complex systems, displaying results and data in a powerful manner (e.g., scientific visualization, multimedia, virtual reality,...), for enhancing collaboration fully exploiting networking facilities, OO technology appears better suited than procedural languages. The principle "divide and conquer" has been known for a long time as an efficient technique to conquer large empires (e.g., large codes). But, how to divide? Both procedural and OO programming employ the principle.The fundamental difference between these two models is the choice of building blocks. In procedural programming, procedures are the fundamental units (usually called subroutines or subprograms). In the object model, basic units are "cells" or "atoms" called objects which contain both data (i.e., state variables associated with the "atom" state at a given time) and methods (i.e., dynamical rules, rules that explain how "atoms" interact in the outside world). In OO terminology, objects encapsulate data and behavior. These objects are individual weakly interacting blocks. Objects interact (exchange messages) to produce collective behavior. OO views the word as composed of objects with well-defined properties. Object dynamics is pictured as interaction among objects. Interactions are mediated by messages that objects exchange with each other. In fact, for a physicist this description may sound familiar as it resembles our modern view of the atomic and subatomic world. This suggests that we could expect interesting analogies between Quantum Physics (QP) and the object model (OM). These analogies are identified and exploited in this work to present an introduction to the OO philosophy. Our examples use C++ as it currently is the most widely used OO language.[4]. The main goal of this work is to provide an introduction to OO concepts for an audience of natural scientists and graduate/advanced undergraduate students in the Physical Sciences. We introduce some of the main OO ideas in this work at three different levels. At the highest level, we discuss general OO concepts, independent of the language. At an intermediate level, and to produce more concrete examples, we express some of the QP concepts[5] in the C++ language. [C++ code is written in this style , and adopts the Taligent notational style[6]]. Usually, in this process we select a particular C++ design, the simplest to illustrate some OO features. Selected designs rarely are the "best" and usually oversimplify the physics. Thus, the code provided in this work is mainly for didactic purposes and not intended for a real project. Section II presents some basic concepts in the object model (OM): abstraction, encapsulation, modularity and hierarchy. They are illustrated with examples from the atomic/subatomic world. Connections between the OM and some concepts in Quantum Physics are presented in Section III. Table 1, at the end of that section, summarizes some of these analogies. Section IV discusses additional analogies between structures in quantum physics and constructs in the object model, and then summarizes them in Table 2. Dynamics in the OM and in QP are discussed and contrasted in Section V. Section VI introduces the problem of object-oriented design of a complex system. Analogies between hypermedia and the path integral formulation of QP are presented in Section VII. Finally, the last section collects some final thoughts and summarizes some of the experiences of earlier scientific users of the object-oriented technology.
II. Basic Concepts in the Object Model
Abstraction is well known to any natural scientist or anybody interested in modeling. It consists of extracting the relevant common features of the system to be modeled, providing adequate generalization, and removing irrelevant details. For example, all protons in the universe share many properties: value of their masses, electric charges, spins,... (data) and the way they interact with themselves and other particles (methods). Protons are still protons, regardless of their location (inside our mouth or in a distant galaxy) or their internal state (i.e., value of their momentum, orientation of their spin,...). Abstraction determines the characteristics of an object that distinguish it from other kinds of objects (e.g. protons are different from neutrons or electrons, but two protons in different atoms are still protons). This is the "outside view" of the object. That is how clients, particles that interact with the proton, see it. It is important to have the right set of abstractions for a given problem domain. For example, to different levels of abstraction, protons and neutrons can be either viewed as different objects, or the same object (nucleon) in a different state. We will return to this later. There is a wide spectrum of abstraction possibilities: objects could closely resemble "real" objects (car object, pendulum object,...) but there could be quite "abstract" objects with apparently "no reason to exist" (shape object, transaction object, photon, Cooper pair,...). Encapsulation is also called information hiding. Clients (particles that interact with protons) do not see a proton's internal structure ("inside view" of the object). That is, protons hide information about their internal structure. In general, the interface of a class captures only the outside view. For example, electrons of hydrogen atoms do not know the proton internal structure. They only see a proton's interface: its mass, electric charge, linear momentum and spin. Encapsulation, then, is the process of hiding all the internal details of an object. Modularity means that a system can be decomposed into a set of weakly coupled modules. Hydrogen gas is composed of many loosely interacting objects (hydrogen molecules). Each molecule is made of two weakly interacting objects (hydrogen atoms). In turn, each hydrogen atom consists of two objects (proton and electron) that collaborate (are bound together) exchanging messages (photons, the messengers, are the carriers of the electromagnetic interaction). In general, one of the most difficult problems in the OO design of complex systems is to "discover' the right modules to mimic the system. This difficulty is analogous to finding the "right" ground state in a many-body problem (e.g., superconductivity) as discussed later. Hierarchy is the ranking or ordering of abstractions. Consider a deuterium atom. It has just a single electron, but the nucleus consists of a neutron and a proton. Electrons in the deuterium atom interact (exchange messages = photons) with charged protons through the electromagnetic interaction. Neutrons are uncharged particles so, at this level of abstraction, electrons see neutrons and protons as different particles (objects). At a higher level of abstraction, now inside the deuterium nucleus, protons and neutrons "collaborate" by sending "attractive" messages to each other (exchanging pions). They view each other as different states of the same particle (in physicists language, they are members of a SU(2) doublet). At still higher levels of abstraction, nucleons (protons or neutrons) are just possible states of more abstract entities (SU(N) multiplets, with N = 3, 4,...) that encompass a large number of distinct particles at lower levels of abstractions. Fig. 1 displays this example of subatomic hierarchical layering.
Figure 1. Subatomic hierarchical layering: in this picture we distinguish three levels of abstraction. In atomic physics, layer 1, we describe the physics in terms of interacting electron and nucleus objects. Inside the nucleus, layer 2, the appropriate objects are protons and neutrons. Finally, at higher collision energy, layer 3, the proton is viewed as made of interacting quark objects.
III. The Object Model and Quantum Physics In QP[5]], the description of the state of a system (say, a particle) at a given time is defined by specifying its state vector. This vector belongs to the state space E (which comprises all possible states of the system). The set of distinct states of a system can either be finite or infinite (countable or continuous). [Of course, the computer representation of the state space is always finite]. The description of the state of an object in the OM follows from the above by just replacing "system" (or "particle") by "object". Examples: 1) Consider an Ising spin or Boolean variable. This object can only take two values: up (on or 1) and down (off or -1). These two distinct states can be represented by the vectors
We have used the so-called Dirac notation | > to denote a state vector. This example is easily generalizable for objects with 3, 4,... states. Given the two states up and down, in QP a state vector could be any linear combination of these two basis vector. The only constraint is that vectors are normalized (i.e., the norm of the vector should be unity). Hence, a more general state vector |s> for the two-state system has the form
The interpretation is the following: the spin is in a state with probability cos^2 (theta) to be |up>, and sin^2 (theta) to be |down>. Conservation of probability (i.e., cos^2 (theta) + sin^2 (theta) = 1) constrains the state vectors to be normalized.
In our C++ design, an object of the type Ising spin is denoted
2) Consider a "classical" three dimensional real vector object. In this case there is a continuum of states. Once a coordinate system is chosen, say, Cartesian, states are labeled by the x, y and z coordinates of the vector. Our vector object can be represented in the Dirac notation as |x, y, z>. In our C++ model, we just call it
3) Consider a spinless particle. It is described by its state vector |k> with k = (kx, ky, kz) the linear momentum coordinates. The quantities ki, i =x, y and z are real numbers. An alternative description of the same particle might be in terms of the position state vector |x> with x a three dimensional vector, i. e., x = (x, y, z). The particle state vector is related to the probability of finding the particle in a particular spacial region (or with a particular value of linear momentum). In our design, we denote the particle Identity [1,2] is the property that distinguishes an object from all other objects. For example, this proton, now in my mouth, is not the same as (but it is identical to) that proton now at a distant galaxy. In QP each object defines its own vector space spanned by a complete set of linearly independent vectors associated with all its possible states. In the OM common usage, identity of objects is always preserved even when states are completely changed. A proton object is still the same object even if its momentum and spin changes because of interaction with other objects. In other words, identity means that there is a unique state vector space associated with each object. Although in classical physics identity is always preserved, in quantum physics and Nature, sometimes an object could either have a "non-sharp" identity, or even completely lose its identity. This could, but usually is not, be modelled in the OM,[3] and it is further discussed in the following sections. Behavior [1,2] is how an object acts or reacts in the presence of other objects, i.e., how it interacts with the external world. Behavior could also be defined as response to actions (i.e., response function). Operations that affect the object and possibly modify its state are called methods or, in the C++ terminology, member functions. In QP, methods correspond to operators, that is, the state of the system is modified by applying an operator (i.e., a matrix) O on the state vector |s1>, producing a new vector | s2> as a result, i.e., | s2> = O | s1> ; The above operation might be written in the OM language (employing C++ notation) as
where
where r = s2 -s1 is the "distance" between the states s1 and s2. In QP, operators are linear (i.e., represented by matrices) acting on linear vector spaces. On the other hand, in real life OO design, operators often are not linear. OO designs commonly employ operations that either change the state of objects (for example, set-methods) or access their state (get-methods). Get-methods measure some object's observables (or in the OO language, read the data encapsulated by the object). Besides these, there are two very important methods called constructor and destructor, which create and annihilate objects. As it could be guessed, they are closely related to the creation and annihilation operators of second quantized quantum mechanics, and they are discussed in the following section. Now we provide some examples,
1) For
The method
where
The methods
2) For the
which rotates any
where the object
3) The linear momentum operator P [denoted P | p> = p |p > , in C++ this reads,
Usually one also defines a momentum transfer operator, Here we summarize the correspondence between OM, QP and linear algebra : TABLE 1. The Object Model, Quantum Mechanics and Linear Algebra
IV. Classes, Hierarchies and Quantum Field Theories Let us first discuss the QP description of a system of many identical particles. Consider a system of two TIsingSpin objects labeled anIsingSpinA and anIsingSpinB . Each one has, associated with it, a 2-dimensional vector space E(a) and E(b) , spanned by the vectors up and down for both objects, anIsingSpinA and anIsingSpinB . To the composite system corresponds a vector space E = E(a) X E(b) (X indicates the direct product of the two vector spaces E(a) and E(b)) spanned by four vectors |A up> X |B up>, |A up> X |B down>, |A down> X |B up>, |A down> X |B down>, corresponding to all possible combinations of states of the spins A and B. Obviously, this discussion is easy generalizable to many objects, say anIsingSpin(i) with i=1,2,..., N. The composite system made of N objects of type (class) TIsingSpin has, associated with it, a state vector space E, the direct product of the individual state vector spaces E(i) for all i. One-body operators, such as SetUpA() , only operate on anIsingSpinA setting its state to up, but do not affect other objects. Mathematical representations of a given vector depend on the choice of coordinates, i.e., a vector has many possible representations. For a system of many particles there is an alternative (equivalent) representation of the system's state vector which does not hinge on the individual state vectors but focuses on the system's properties such as total spin (sum of the spin of individual particles), total number of particles, total energy/momentum,.... This alternative representation of the same physics known as second quantization [5] is closely related to a "class view" in the object model. Although second quantization is the preferred formulation of the non-relativist quantum mechanical many-body problem, it is the only choice when the fully relativistic extension is considered. This is because in the relativistic view there cannot be a single (or a few) object simplification of reality but there must always be a multitude of coexisting objects. An important feature of the second quantization formalism is the existence of the creation and annihilation operators. These operators, are closely associated with the constructor and destructor operators common in most OO languages (such as C++). In the second quantization formalism, Proton becomes a quantum field. Associated to it, there is a creation and an annihilation operator. Similarly, in the OM TProton becomes a class. Associated to it, there are constructors and destructors. Using C++ notation, the creation (constructor) and annihilation (destructor) operators are denoted TProton() and ~TProton() , respectively. [In C++ there can be several constructors.] State vectors are now associated to systems with zero, one, two,..., particles (quanta) each in one of its possible allowed states. The null particle system is known as the vacuum (i.e., a class that has not been instantiated). Contrary to one's naive expectation, the null particle state could be quite complex and its effects may be observable. Creation operators and constructors serve very similar purposes. For example, in C++ one instantiates (creates and initializes) the class TProton , creating an object (particle) of the class, which we call aProton TProton aProton; In the QP language aProton is a one-particle state (a single quantum of the Proton quantum field). The constructor above is the so-called default constructor as it does not take any argument (it might use a random number generator to select a value for the proton's momentum). Now suppose that we would like to create another proton with a given momentum, aMomentum = (aMomentumX, aMomentumY, aMomentumZ) . We would then design a constructor that takes an argument, i.e., the value of the momentum: aMomentum , TProton bProton(aMomentum); aMomentum is an object (real three dimensional vector) of the class TVector3D . Before using it above, it might be instantiated as follows TVector3D aMomentum(aMomentumX,aMomentumY,aMomentumZ); where TVector3D(x,y,z) is one of the constructors of the class TVector3D and takes the three arguments in parenthesis to be the values of the Cartesian components of the vector object to be created (see Appendix A). Constructors instantiate objects. Using the constructor we can instantiate as many proton objects as desired. Suppose we would like to create an oxygen nucleus system that contains eight protons and eight neutrons with arbitrary (randomly chosen) momenta, we could proceed as follows TProton aProton[8]; TNeutron aNeutron[8]; It is usual practice in C++ to declare a class, say TProton , in a file called a header file while implementation of functionalities is placed in one (or several) source files. Clients of TProton usually will need the header file, Proton.h, (interface of TProton with the exterior world), and seldom, if the design is correct, would information about actual implementation be required. The declaration of the class TProton follows
To accomplish information hiding, classes have public and private members. (In fact, there are also protected members, as discussed in the Appendix B). Members include both data members ( fgNumber , kMass ,...) and member functions or methods (constructors/destructor, get/set methods,...). Public members are accessible to any client that uses the class definition (i.e., includes the header Proton.h describing TProton 's interface). [In turn, the class TProton is a client of TVector3D since it uses objects of this type. Then, the header Vector3D.h (which is given in the Appendix A) must be included (first line of the above code) allowing TProton access to public members of TVector3D .] The public members of the class TProton are the constructors, the destructor and the set/get methods. Private members can be accessed only by objects of the class, i.e., by protons. They are hidden from other types of objects, such as electrons. Private data members in the class TProton include the value of its mass, electric charge, momentum, and the total number of protons. In the design above, we have chosen to provide public access to the proton's private data through get methods. Static members act as a global class variables, i.e., all objects of a particular class have access to the same variable. In the class TProton , fgNumber , kMass and kElectricCharge are all static. Besides this, the last two data members are also constant (const) as these values are fixed for all protons. In contrast, fgNumber changes as protons are created or destroyed. One of the weakness of this design is that any proton object "knows" (i.e., can access) the total proton number, fgNumber . Alternative TProton designs are discussed in Appendix B. The private data member fMomentum is an object of the class TVector3D . It is not static as every object owns its own value for fMomentum . Neither is it constant since this value changes as aProton object interacts with other objects. In Appendix B, we start at a higher level of abstraction, defining the classes TParticle and TNucleon . In that design (see Fig. 2) TNucleon directly derives from TParticle , and in turn, TProton and TNeutron derive from TNucleon . Inheritance is one of the fundamental characteristics of OO programming. In C++, it is supported by the mechanism of class derivation. Derived classes inherit properties (i.e., data members and member functions) from the parent class (known as the base class). Derived classes usually add new members and/or override methods (i.e., provide different implementation). For example, TNucleon is a base class relative to TProton and TNeutron .Then, implementation of most functionalities required by derived classes (such as TProton and TNeutron ) is already provided by (inherited from) their base class ( TNucleon ). In Appendix B design, the class TProton only needs to override the constructors and destructor, and to implement just an additional method: GetElectricCharge() . Notice that the declaration of TProton in Appendix B is much simpler than that presented above, as there we have taken advantage of inheritance.
Figure 2. A possible class diagram of the particle "zoo" displaying single inheritance relationship among classes. In this design, TParticle and TChargedParticle are abstract base classes (they cannot be instantiated), all other classes are concrete. Should TPion and TNucleon derive directly from TParticle , or via TChargedParticle ? Should TQuasiParticle derive from TParticle , or be at the top of the hierarchy in parallel to TParticle ? In OO design of complex systems, the class taxonomy is usually a highly non-trivial problem. At the highest level of the hierarchical structure (see, Figure 2) we define the class TParticle that encompasses properties shared by all particles (e.g., fMomentum , SetMomentum() , GetMomentum() ...). This class is called abstract base class and is never instantiated. That is, we never create quanta of TParticle , but only create objects of its derived classes such as TProton , TElectron , TPion ,.... Nevertheless, abstract base classes are useful as they serve to set a common protocol (common notation for all derived classes). Figure 2 presents a possible single inheritance class diagram of the particle "zoo". Protons are fermions (the value of the proton's total spin is half-integer, i.e., 1/2); and they are also charged particles. At higher levels of abstraction we might define the abstract base classes TFermion and TChargedParticle . In this higher abstraction, TProton would inherit from both base classes. This is an example of multiple inheritance. Inheritance is just one (although a very important one) of the possible relationships among classes. It is also known as "kind of" relationship since, say, TProton is a "kind of" TNucleon . Another important class relationship in OO design is "part of". For example, protons are made of three quarks. Then, aQuark[3] , an array of three quark objects, is "part of" a proton. For example, a possible TProton class design might include TQuark aQuark[3]; say, as a private data member. This design makes more explicit some aspects of the proton's internal structure which may be required in some problem domain. Which is the "best" class design and the "best" class taxonomy? The answer strongly depends on the piece of reality we try to capture and the questions we intent to address. These are some interesting issues in OO design further discussed in Section VI. We now introduce polymorphism which we exploit in the coming section. Polymorphism means that a single name may denote methods of many different classes related by some common base class (these methods might act differently on objects belonging to different classes). For example, we might provide the method GetElectricCharge() in the class TChargedParticle . A client's code then works correctly for, say, objects of the classes TProton , TElectron , ..., (returning +1, -1, ...) which derive from TChargedParticle even if the compiler only knows these objects are of type TChargedParticle . That is, code works correctly even if actual values of particles' electric charges are only known at runtime. Polymorphism combines the features of inheritance with dynamic binding (that is, the types of variables and expressions is not known until runtime) and is one of the most important concepts in OO. Finally, to conclude this section we summarize some of the analogies between the OM ("class view") and quantum field theory. TABLE 2. Classes and Quantum Fields
Dynamics of a many-object system is the result of object interactions. Objects interact with each other exchanging messages thus changing their states as time evolves. What is the OM formalism used to describe this picture and how does it relate to the QP description? This section discusses and compares the OM and QP descriptions of dynamics. Also, the useful property of operator overloading is introduced. Suppose we would like to describe an electron-proton scattering process. Initially there is an electron object in the state aMomentum_K1 and a proton object in the state aMomentum_P1 . After an interaction, which is mediated by a messager object called aPhoton , both objects (electron and proton) transition to different states, say aMomentum_K2 and aMomentum_P2 , respectively. In QP the interaction between quantum objects is often displayed in Feynman diagrams [5,8] For example, Fig. 3 shows a Feynman diagram for the electron-proton scattering process. [In fact, the interaction of Fig. 3 is just one (although the most relevant) of the very many possible ways proton and electron objects can interact electromagnetically exchanging momentum]. How might this be described in the object model?
Figure 3. Feynman diagram describing electron-proton electromagnetic scattering. Two objects (proton and electron) in some initial states (|P1> and |K1>) interact exchanging a message (a photon). After the interaction, the objects are in different states (|P2> and |K2>). 1) Using the appropriate constructors we instantiate an electron, myElectron , and a proton, myProton , with momenta aMomentum_K1 and aMomentum_P1 TElectron myElectron (aMomentum_K1); TProton myProton (aMomentum_P1); 2) Using the method SetMomentum() , we change the values of the momenta to their final values: aMomentum_K2 and aMomentum_P2 . In Appendix B design, the method SetMomentum() is provided in the abstract base class TParticle . The classes TElectron and TProton (which derive from TParticle ) inherit this method. myElectron.SetMomentum (aMomentum_K2); myProton.SetMomentum (aMomentum_P2); The values of, say, aMomentum_K2 is constrained due to the momentum conservation law, i.e., aMomentum_K2 = aMomentum_P1 + aMomentum_K1 - aMomentum_P2; [Note that in the above equation, and in some of the forthcoming equations, we assign, add and substract TVector3D objects as if they were built in types]. Alternatively we might have used the method MomentumTransfer() instead of SetMomentum() as follows myElectron.MomentumTransfer ((-1)*aMomentum_Q)); myProton.MomentumTransfer (aMomentum_Q); where aMomentum_Q = aMomentum_P2 - aMomentum_P1; Momentum conservation in these simple models must be implemented by hand. We now present another model that builds in momentum conservation.The above representations only use one-body operators (i.e., SetMomentum() or MomentumTransfer() , in the class TProton , only acts on objects of the type TProton ). What if we would like to represent aPhoton object that mediates the electron-proton interaction? A possible way to accomplish this is by using the methods EmitPhoton() and AbsorbPhoton() , which take as argument an object of type TPhoton . The implementation of these methods could easily build in momentum conservation in a natural way. For example, after creating our proton, electron and photon TElectron myElectron (aMomentum_K1); TProton myProton (aMomentum_P1); TPhoton myPhoton (aMomentum_Q); we apply the methods EmitPhoton() to myElectron and AbsorbPhoton() to myProton : myElectron.EmitPhoton(myPhoton); myProton.AbsorbPhoton(myPhoton); where we have assumed that both TElectron and TProton derive from TChargedParticle , and that the methods EmitPhoton() and AbsorbPhoton() in the class TChargedParticle are implemented to guarantee momentum conservation. This might be done as follows: myChargedParticle.EmitPhoton(myPhoton) sets myChargedParticle 's momentum to aMomentum_K2 = aMomentum_K1 - aMomentum_Q, while myChargeParticle.AbsorbPhoton(myPhoton) sets myChargedParticle 's momentum to aMomentum_K2 = aMomentum_K1 + aMomentum_Q. where aMomentum_K1 is the initial value of myChargedParticle 's momentum. This representation of the interaction of two objects mediated by a third one (messager) is more closely related to that of QP shown in Fig. 3. When describing the dynamics, it is convenient to use some objects, say from the class TVector3D , just as if they were built in types. For example, we might want to add and subtract TVector3D objects as in the momentum conservation equations of above. In the interface of the class TVector3D presented in Appendix A we have overloaded the assignment, the multiplication, and the addition/subtraction operators. Overloading an operator means that the compiler recognizes by context which operator implementation is being requested by the user in expressions such as the above ones. In other words, by overloading, for example, the + and - operators, we "teach the compiler" how to add/substract TVector3D objects (using the symbols + and - in the familiar way). Operator overloading is a very nice and quite useful feature of some OO languages. As the exchange energy between relativistic interacting particles increases other interaction processes become important. Consider an electron and its antiparticle, the positron. Given these objects at some initial time, at a later time they "vanish" and transform themselves into, say, a proton object and an antiproton object. This process is represented in the Feynman diagram of Fig. 4. This is an interesting example of objects completely losing their identity. Also, as in the scattering process of Fig. 3, this process is mediated by a photon object. This physics is not "naturally" captured in the current C++ language. [But, of course, it can be modelled]. In fact, OO languages other than C++ may offer more natural mechanisms for such a modelling, for example Smalltalk's "become" method.
Figure 4. Feynman diagram showing electromagnetic electron-positron annihilation. Two different objects (electron and positron) in some initial states (|K1> and |K2>) "annihilate" each other. An intermediate object is formed (photon), which then "becomes" two distinct objects (proton and anti-proton) in states |P1> and |P2>. As we have seen in this and the previous sections, in QP states have a "probabilistic" interpretation, and objects can sometimes confuse/lose their identities. They are summarized below: 1) When measuring a quantum system, state vectors just predict probabilities for objects to be in some states. Seldom does the state vector predict with certainty a unique state (this case corresponds to state vectors that are eigenstates of the complete set of observables). 2) If there are many identical quantum objects (i.e., objects that belong to the same class) confined to a "small" region in space their identity can get confused. This is a consequence of the uncertainty principle as position/momentum of objects cannot be measured simultaneously with infinite precision. 3) Finally the "worst case" occurs in relativistic quantum mechanics. In this case, objects can completely lose their identity. Then, objects of a given class could transform into objects of another (e.g., electron/positron into proton/antiproton). This effect is a consequence of both the uncertainty principle and also of the energy-mass equivalence; i.e., the "stuff" encapsulated by the electron/positron objects transforms into an equivalent "stuff" now encapsulated by other types of objects: proton/antiproton. In the OM literature usually states are not "probabilistic" and objects have a sharp identity as in "classical physics"[3]. On the other hand, this is not a limitation of the OM which is equally well suited to model QP. Design of appropriate classes and methods may be challenging. VI. Object-Oriented Design and Effective Hamiltonians. FrameworksSuppose we would like to design and implement an air traffic control system. How to identify the key abstractions in the problem space? How to identify classes and objects in an OO design? What are the possible relationships among classes? Classes (such as TAirplanes , TRunways ,...) are static and their relationships are fixed before the execution of a program. In contrast, objects (such as a new runway, new airplane...) are dynamic. They are constantly created and destroyed during the lifetime of a typical application. The identification of appropriate classes and objects is the hardest problem of OO design[1-3] In fact, in this section we identify analogies between OO design and the problem of finding the "elementary components" of complex systems (for example, superconductors). In many-body theory, this is the problem of finding the effective Hamiltonian that describes the physics of interest. At first glance, OO design may seem straightforward: just mimic the objects of the outside world and their interactions, relevant to the piece of reality to be captured in software. This is not the case in real OO design. In general, reality is too complex to be fully captured in a design. On the other hand, many of the outside objects/interactions may be totally or partially irrelevant to our problem. For example, in a naive design of a payroll one could include TEmployee objects, TCheck objects, TPen objects, TInk objects, TBank objects,.... On the other hand, a more sound design might just introduce TEmployee objects that pay themselves recognizing the irrelevance of other objects such as aBank , anInk , aPen , etc. to the problem of interest. In the process of abstraction, one "invents" a TEmployee object with properties which do not correspond to those of a "real" employee, but substantially simplifies the design. Moreover, to obtain tractable and sound designs, one may introduce " abstract", "intangible", or "totally imaginary" objects that "do not have any resemblance to reality". For example, in a "computer graphics window" design, one may use TAnimation objects (i.e., translation operators) that move things around, and objects of the types TShape , TColor , TSize ,... . In the design of a complex system one has to identify key abstractions, propose some candidate classes and objects to mimic the system, and conjecture some class taxonomy. Some of this has been briefly discussed in Section IV. What are observables? It depends on the observer's interest and ways of probing the system. For example, given some TAirplane objects in anAirport , one may be interested in either their size, color, when they were built, airlines to which they belong, the number of available seats, the type of engine, etc. Choosing the appropriate "degrees of freedom" usually is a highly non-trivial exercise, and OO designs depend critically on this choice. In QP one is confronted with similar situations, for example, given a proton, its momentum might be the observable of interest for some low energy experiments, at higher energies one may be interested in the momenta of each quark. Alternatively, the proton's spin may be one of the selected observables if interested, say, in the hydrogen hyperfine structure. Or protons' degree of freedom may be totally irrelevant, say, if describing hydrodynamic properties of water; even though protons are "part of" water. How does one identify "classes and objects" and their relationships and interactions in Natural Sciences? The components of a system are usually determined by how the system "breaks" under "minimal forces". For example, oxygen gas is made of oxygen molecules. As we apply stronger forces (at higher collision energy), molecules break down, and now the system is made of oxygen atoms, ions and free electrons. Substantially increasing the energy of our probes, we see our system composed of electrons, protons and neutrons. At even higher collision energy one discovers that protons and neutrons are made of quarks. This, again, is an illustration of the hierarchical structure of Nature. "Minimal unit" is an ambiguous concept that strongly depends on "context": depth of penetration into the structure, physical conditions and phenomena to be described (i.e., the kind of experiment selected to explore the system). Given our oxygen gas at room temperature, we view it as composed of molecules when interested in specific heat. On the other hand, if interested in, say, electrical conductivity we instead regard the gas as made of positive and negative ions. One of the most basic problems of Physics is to "find" the "fundamental objects" or "elementary components" of complex systems. This problem is illustrated by superconductivity. Superconductors are materials that offer almost no electrical resistance. Hence electrical currents circulate for months with very little heat dissipation. Conduction properties of metals can be explained in terms of interacting ion and electron objects, but interactions among these type of objects cannot help explaining superconductivity. Superconductivity was discovered in 1911, but it took almost 50 years find a satisfactory theory. What are the relevant "objects" to describe superconductivity"? The BCS (Bardeen, Cooper and Schriffer) theory of superconductivity has shown that "the" sought "object" is the so-called Cooper pair. A Cooper pair is an "atom" made of two electrons that weakly attract each other (attraction mediated by the host ions) and which behaves like a whole. This is an important point, although "free" electrons repel each other (Cooper pairs cannot exist in isolation from the material environment), in the appropriate environment (inside a superconducting metal) they, indeed, form bound states and behave as a whole identity. Cooper pairs are called quasiparticles, as they do not exist in isolation. Quasiparticles, as animals, need their own habitats to survive (e.g., superconductivity only occurs for a few metals in some range of temperature, external fields,...). In contrast, protons and electrons are particles. They can exist in freedom. The Cooper pairs (bosons) are the carriers of electricity in a superconductor, and are much more effective in their task (conducting electricity) than electrons (fermions), carriers of electricity in normal metals. How do we "solve" a complex many-body problem in physics? Let us again discuss superconductivity. Given a metal made of ions and electrons, one searches for the appropriate class or classes that capture the physics of the problem. As reality is too complex, only essential features can be incorporated if the model is to be mathematically (and/or computationally) tractable. One hopes to write the so-called effective Hamiltonian Heff of the system Heff = H0 + HI , with H0 the free Hamiltonian containing the fields (classes) relevant to our problem. For example, in the superconductivity case, the class of interest is TCooperPair although naively, one could have said that the "right" classes were TIon and TElectron . The effective Hamiltonian is an operator, written in terms of the TCooperPair creation and annihilation operators. H0 describes a system of "non-interacting" Cooper pairs (that is, there may be 0, 1, 2,... objects of the type TCooperPair ). The second term HI describes the TCooperPair interface, that is how these objects interact among themselves, so it is called the interaction Hamiltonian. Interaction is supposed to be weak for the effective Hamiltonian to be meaningful, so the objects which encapsulate data (such as mass, electric charge,...) and methods (such as SetMomentum() , ...) conserve their identity as long as objects are in the proper habitat (limit of validity of the effective Hamiltonian). Interactions describe the object's interface with the rest of the world (outside view). Object-Oriented design is facilitated by good class libraries. These libraries provide the "atoms" or basic building blocks to be used in our code. For example, for a linear algebra project, one may need classes such as TVector , TMatrix ,.... The atoms are not "rigid" units but quite flexible. The user can modify the building blocks deriving his/her own classes from those provided (for example, the user can change some methods, add new data members,...). Suppose the class TMatrix is provided, but we need TSymmetricMatrix . We just derive this class from TMatrix inheriting all its properties and just adding the symmetry constraint (some relation among data members). We do not need to implement, say, matrix multiplication as this operation is inherited from the parent class, TMatrix . Then, design will consist in using classes provided by the library (maybe after subclassing some of them) in conjunction with other classes designed by the user. Finally, the user interconnects all parts of the system. If we would like to model, say, oxygen gas, it would be much more convenient to have as fundamental building blocks molecules of oxygen (and maybe oxygen atoms and ions) with the proper interactions, than, say, quarks and leptons interacting via weak, electromagnetic and strong forces, or protons and electrons interacting electromagnetically. In fact, had we started with quarks and leptons, we may have never accomplished our project as it is an immensely more difficult problem than if one starts with the "right" building blocks. Frameworks in the OO technology are the analog to the "complete design" of the oxygen gas using oxygen molecules building blocks (and possibly oxygen atoms and ions) interacting via van der Walls forces (and possibly electromagnetic ones), and, maybe, confined to some container with some geometry and boundary conditions. Frameworks encapsulate "collective behavior". This "collective behavior" is the result of several classes interacting in a particular well-defined manner. On the other hand, frameworks are not canned programs but flexible designs. For example, we could add additional particles, new particle types, modify or add new interactions, change the container geometry and/or boundary conditions,... by subclassing and overriding. Frameworks are a very natural way to reuse higher level designs. In conclusion, the difficult problem of modeling a complex system could be substantially reduced by good class libraries and frameworks. We will elaborate more on this point in the last section.
VII. Multimedia, Parallel Universes and Path Integrals. A very useful mathematical representation of quantum mechanics is via path integrals[6,8] Suppose one creates an object, say, myVector3D that belong to the class TVector3D , at time t1 in some state | s1 >, where s1 consists of the variables that define the state (say, the three Cartesian coordinates of the myVector3D object). As previously discussed, the state vector has, associated with it, an abstract vector space where all states can be represented. In our example, the state space is just a (usual Euclidean) three-dimensional space. As time evolves, the state vector changes and this can be pictured as the motion of the point representing the current vector's state in the state space. In QP, due to the "probabilistic" nature of the state vectors [i.e., quantum state vectors only give probabilities for the object, when measured, to be in given states], objects created at (s1, t1) and annihilated at (s2, t2) can make the transition from their initial to their final state in many (sometimes, infinite) possible ways (paths). See Fig. 5. In contrast, in classical mechanics there is just a single possible path (that which minimizes certain function called the action related to the Hamiltonian of the system). In QP all paths are possible but each one is weighted by its action. In other words, the action on a given path is a measure of the probability of that path. Using the path integral formulation of QP, one obtains identical results as using the alternative operator representation sketched in previous sections (i.e., the two representation are equivalent).
Figure 5. Given two events s1 and s2 at times t1 and t2, such as the position of a moving ball at two distinct times, in classical mechanics there is just a single path (i.e., trajectory) which could join both points. This is the path that minimizes the action. In contrast, in QP all paths are allowed with some probability (i.e., each path is weighted by the path's action). In hypermedia, say, an interacting book, we could move from the beginning to the end of the story in many ways. For example, in each page, by clicking on some objects in some order we "choose" some trajectory in the "story" space. One controversial interpretation of QP (many-universe interpretation)[9] says if something physically can happen, it does, in some universe. In other words, each of the very many paths in the state space do occur in some universe. Then, physical reality would consist of a collection of universes (each running all possible scenarios of a play). In fact, this many-world model is approximated in hypermedia. In hypermedia[10], there is an information/event (state) space for a story one wishes to tell (e.g., an interacting book). The space can have any number of dimensions. Actual events are represented as points in the space. Navigable paths are curves in this space linking various events together. These curves intersect at specific events, and the user can, in principle, explore the full space. In hypermedia (and virtual reality) navigation in the event space is usually manual. Yet, provided with a model (Hamiltonian), a simulation engine either could select a single path in the information space (classical physics), or assign probabilities to each path (quantum model). VIII. Present and FutureIn the last section we collect some thoughts and summarize some of the early scientific users'experience with OO. The object model provides a very natural language for modeling Nature, one that could closely mimic in software most mathematical structures used by natural scientists. The principle of abstraction, a basic pillar of natural sciences (and of any other science) is one of the most fundamental concepts in object-oriented design. Because of abstraction one can attack difficult problems by isolating relevant features for the piece of reality to be captured in the model. Also, abstraction allows one to find common characteristics in apparently very different problems. Moreover, abstraction sometimes permits the "decoupling" of various aspects of a problem into "orthogonal" components which can be mathematically modeled (or implemented in software) independent of each other. OO is sufficiently mature to implement many physical models. In particular, the C++ language is widely available (on PCs, workstations and supercomputers) and portable. Some OO languages appear well suited for the tasks of scientific software development[12,13] In particular, the class concept together with the facility to overload operators allows user-defined data structures (such as rational numbers, vectors, tensors, spinors, group theoretical operations,...) to be handled in same way as built in types (such as integer or float)[14] Library support is not as ample, and compiler technology is not as mature for C++ as for Fortran (which has been the favorite scientific programming language for more than forty years). Currently, code execution speed is not as good as Fortran's. In fact, several workers are currently using dual language (Fortran/C++) implementations[12] to get the best of both worlds. Anyway, the situation in these fronts is rapidly improving. Class libraries provide classes such as vectors, matrices,..., reusable building blocks for larger problems. Object-Oriented building blocks are flexible, permitting subclassing to satisfy user's specialized needs. (For example, one might subclass the class TComplexMatrix to obtain SU(3) matrices). Currently there are several commercial (M++[15] , Math.h++, Lapack.h++,[16]...) and some public domain (NIH class library [17],...) class libraries for scientific computation. LAPACK, a well known linear algebra library, has already been extended to C++. ScaLAPACK++ is an object-oriented C++ library for implementing linear algebra computations on distributed memory multicomponents[18] Available numerical class libraries support arrays of various types, parallel arrays, linear algebra classes, polynomials, random number generators, statistical objects, geometrical objects,... In several National Laboratories, there are teams actively working on challenging OO numerics projects. For example, MatResLib is an OO material response library written in C++ at Sandia National Laboratories[19] Some large scientific projects are now being written (or rewritten) in C++[20,21] Usually, the choice of an OO language over a procedural one has been made to satisfy fundamental requirements such as portability, maintainability and extensibility. For example, recently seven radio astronomy observatories from around the globe joined forces to develop an OO data processing system called AIPS++ (the Astrophysical Image Processing System)[21] that is to replace an older system written in Fortran 66. When programmed in procedural languages (e.g., Fortran) the physics is closely interwoven with numerical analysis, memory management, the geometry of the problem (such as shape of the container and boundary conditions)...[12,22] Large bodies of codes are not only difficult to write, but are even more challenging to debug. A very important advantage of OO languages is that they can much better isolate numerical analysis, system geometry, etc., from the physics of the problem[12,22] In addition, data abstraction enhances the comprehensibility of the code, modules can be altered (debugged, modified, upgraded) without affecting other modules. These nice features of OO have been exploited by many scientific users. For example, sets of coupled partial differential equations appear in a large variety of problems in physics, such as computational fluid dynamics. A recent paper[22] considers a Navier-Stokes simulator for compressible gas flow and uses adaptive mesh refinement algorithms. The C++ code (the authors employ Fortran for low level numerics) has been written in a "dimension independent" fashion employing geometrical objects (e.g., intersections and unions of "d-dimensional" box objects). Once the code was proven to work in d = 2 then the extension to 3 dimensions was effortless. In the same code, for example, it was also painless to add a parabolic term to the Navier-Stoke equation to include diffusive transport of heat and momentum. Previously, debugging the old Fortran code for the three dimensional problem was mind boggling and the incorporation of diffusion term in the model required much more effort. OO is well suited to parallel computing. Objects are already "natural units" to be distributed in a convenient fashion among the processors. C++ can be extended to support concurrency (active objects own their threads of control)[23,24] Parallel computing using procedural languages has been very successful in large problems with homogeneous structures (matrix computations, homogeneous fluids,...). Homogeneity often guarantees a balanced allocation of work across the processors, as well as efficient communication between nodes. More complex systems such as disordered systems, inhomogeneous fluids,... suffer from space-time irregularities For example, flow computations of inhomogeneous fluids may require dynamically and locally modifying mesh size adding or deleting nodes during computation. For efficient use of parallel computing, work must be relocated at run time among the processors to maintain acceptable workloads. Also, it is usually desirable to support the possibility of node failures (fault tolerance) so if a node fails the computation is not stalled. These tasks are naturally implemented using OO technology (e.g., customize active objects to manage workload distribution)[24] Currently, parallel computing is reserved for a small group of practitioners. This may not be a result of the intrinsic difficulty of the problem but of tools, methodologies and development environment support used to treat it. Some researchers[25] have attained performance comparable to procedural technology in parallel computing, with less effort, using OO technology and higher levels of abstractions. Should a natural scientist become a programmer to take full advantage of modern technologies, such as computer simulation, scientific visualization, parallel computing, virtual reality,...? Of course, the obvious answer is that natural scientists would like to profit from these powerful technologies but also keep some time for science! Here, object techniques, and in particular framework technology can prove very useful. Frameworks are reusable OO designs for domain-specific problems. In fact, framework programming is a logical extension of OO programming. For example, a team of physicists/chemists could design a molecular dynamics simulation framework (using existing class libraries and frameworks). [26,27] This framework would contain all important features required to produce (maybe, parallel) molecular dynamics simulations and display data in a variety of useful forms (scientific visualization, virtual reality,...)[28] Clients could use the framework as it is (as a canned simulator) but, with little effort, they could tailor it to fit their needs. For example, they could add additional particles, other type of particles, other properties to existing particles, add/modify interactions, change boundary conditions,... . This is simply done by subclassing and adding new methods and data members to existing classes. Thus, frameworks could provide even to a "computer illiterate" natural scientist (but who knows some basic OO design) easy access to simulation, visualization, parallel computing, virtual reality,... . The hardest work would be done by designers of classes and frameworks at various levels. Natural scientists could devote their time to doing science while enjoying simple, powerful and flexible computational tools. AcknowledgementsI want especially to thank Clayton Lewis, Douglas McKay, Peter Martin and Ryoji Watanabe for very useful discussions and critical reading of the manuscript. Thanks to Jack Douglas, Yinsun Feng, Peter McInerney, Colin McMaster, Mario Nemirovsky, Jon Okada, Jim Thomas and David Wilson for critical reading of the manuscript. Thanks also to Eric Bond and Joyce Uggla for help in editing the manuscript.
Appendix A
In this Appendix, we provide a C++ declaration and implementation of the class TVector3D , illustrating the important C++ feature of operator overloading. To take full advantage of the Appendices, some basic background in C and C++ is required (either an introductory course in C++, or some exposure to basic C++ through any of Refs 4 or other C++ textbook). The header Vector3D.h declares the class TVector3D
The implementation of the class TVector3D follows
In this design, the default constructor returns a null vector. Alternatively, one might provide an implementation using a random number generator so the constructor would instantiate a random TVector3D object. The operators =, +=, ... are messages sent to an object of the TVector3D class. Since the name of this object is not known, in the C/C++ language it is denoted *this.
Appendix B This Appendix presents C++ code for some of the examples discussed in this work, such as the abstract base class TParticle and the concrete classes TNucleon , TProton and TNeutron . Here we have not attempted to produce the "best" class design, but just to provide an illustration of some of the OM features using C++. In the file Particle.h we declare the abstract base class TParticle which encompasses common features of objects of type TParticle
The class TParticle contains just one data member, fMomentum , which is protected. Protected means that only derived classes can access this member. Alternative designs could have chosen to include, say, other particle attributes such as kMass , kElectricCharge , etc. In our design these other data members are included in some of the derived class (e.g., TProton and TNeutron ). TParticle is an abstract base class, thus it cannot be instantiated. An abstract base class has at least one pure virtual function. A pure virtual member function (e.g., GetNumber() ) is not implemented in the base class but derived classes must provide its implementation (this is indicated by appending " = 0" after the method's declaration). Derived classes (such as TChargedParticle , TPhoton , TNucleon ,...) usually implement constructors/destructors, and may add additional methods (such as AbsorbPhoton() , EmitPion( ), ...). Additional data members may also be added (such as kMass , kElectricCharge ,...). Virtual functions (such as the get and set methods, and the destructor of class TParticle ) allow derived classes to replace (override) these functions' implementation polymorphically. Suppose that the method GetElectricCharge() is defined in the class TChargedParticle . Then, the derived classes TElectron , TProton and TNeutron would then inherit this method but should provide different implementations (i.e., override this method). For example, GetElectricCharge() returns 0 for aNeutron , 1 for aProton and -1 for anElectron . The source file Particle.C contains the implementation of the GetMomentum() and SetMomentum() methods and is given below
There could be several intermediate classes between TParticle and TNucleon (such as THadron , TMultipletSU4 , ...). Since there are not many interesting additional OO features to illustrate, and for a sake of simplicity, we derive TNucleon directly from the abstract base class. Thus, in another file, Nucleon.h we declare the class TNucleon , which is a concrete class (it can be instantiated), and directly derives from (i.e., is a subclass of) TParticle
The first (#include) lines indicate to the compiler that information declared in the headers <Particle.h> and <Pion.h> will be required. The source file Nucleon.C follows
The class TProton (which derives from TNucleon ) is declared in the header Proton.h
Most of the data and methods of TProton are inherited from TNucleon , so they have already been implemented. Hence little additional work is required. Constructors/destructor are overridden and the method GetElectricCharge() is implemented in the source file Proton.C
For the class TNeutron code is identical to that of the TProton with the replacement TNeutron by TProton , and the value for the electric charge, kElectricCharge , zero instead of one. For the code given in the Appendices to compile and work, the reader must implement the class TNeutron as discussed above, and also declare and implement TPion which could directly derive from TParticle . In this case, TPion is almost identical to TNucleon replacing Nucleon by Pion (the methods EmitPion() and AbsorbPion() are not required). This provides the reader all ingredients necessary to describe, in the main program, interactions between protons and neutrons. For example, one might have
to describe a pion exchange process pictured in a Feynman diagram identical to that of Fig. 3 replacing electron by neutron, and photon by pion. As stated before the design of the Appendices are just for illustration. One of the drawbacks of our design is the presence of the global quantity fgNumber , the number of particles of a given type. This information is available to all particles of a given type (in a more sound design, a given particle should not be aware of how many particles of the same type are in the universe). In a more mature design, one might have, for example, an Universe object which acts as a manager of the particles and their interactions. This object might have a "clock", might keep track of the number of particles of each type and of their interactions, might apply forces to particles, etc. References1. For one of the best books on object-oriented programming see, G. Booch, Object-Oriented Analysis and Design with Applications (Benjamin Cummings, Redwood City, 1994). For an excellent introduction to object-oriented technology see, D. Taylor, Object-Oriented Technology: Manager's Guide (Reading, MA, 1992) 2. N. Goldstein and J. Alger, Developing Object-Oriented Software of the Macintosh: analysis, design and programming (Addison-Wesley Pub. Co, New York, 1992). B. Meyer, Object-Oriented Software Construction (Prentice Hall, Hemel Hempstead, U.K., 1988). 3. I. Graham, Object-Oriented Methods (Addision-Wesley, Wokingham, England, 1994). This interesting book provides a very comprehensive survey of object technology. It also discusses fuzzy objects as a way of representing uncertain knowledge. 4. There is an extensive literature on C++. See, e.g., B. Stroustrup, The C++ Programming Language (Addison-Wesley, New York, 1991); M.A. Ellis and B. Stroustrup, The Annotated C++ Reference Manual (Addison-Wesley, New York, 1990); S. B. Lippman, C++ Primer (Addison-Wesley Pub., Reading, Ma., 1992); and K. Weiskamp and B. Faming, The Complete C++ Primer (Academic Press, New York, 1992). M. P. Cline and G. A. Lomow, C++ FAQS - Frequently Asked Questions (Addison-Wesley, New York, 1994) 5. There are many excellent books on quantum physics, see, e.g., Ramamurti Shankar, Principles of Quantum Mechanics (Plenum Press, New York, 1980). See also, H. Frauenfelder and E. M. Hanley, Subatomic Physics (Prentice Hall, Englewood Cliff, NJ, 1991). For a non-technical introduction to quantum physics, see, e.g., C. Schwarz, A Tour of the Subatomic Zoo, A Guide to Particle Physics (American Institute of Physics, New York, 1992). An older and now classics text on quantum field theory is J. D. Bjorken and S.D. Drell, Relativistic Quantum Fields (McGraw-Hill, New York, 1965). See also, Ref. 8. 6. Taligent's Guide to Designing Programs : Well-Mannered Object-Oriented Design in C++ (Addison-Wesley, Reading, Ma, 1994). 7. For a very nice and non-technical discussion on the subject, see M.I. Kaganov and I.M. Lifshits, Quasiparticles (Mir Publishers, Moscow, 1979). 8. R. P. Feynman and A. R. Gibbs, Quantum Mechanics and Path Integrals (McGraw-Hill, New York, 1965). See also, C. Itzykson and J.B. Zuber, Quantum Field Theory (Mc Graw-Hill, New York, 1980). 9. The Many-Worlds Interpretation of Quantum Mechanics, ( B. de Witt and N. Graham, eds., Princeton, NJ: Princeton University Press, 1973) . 10. See, e.g., R. S. Wolff, Computers in Physics 7, 426 (1993). 11. For a comprehensive discussion on modeling in Natural/Social Sciences, and on the theory of modeling, see J. L. Casti, Reality Rules : Picturing the World in Mathematics , Vol 1: The Fundamentals and Vol 2: The Frontier ( J. Wiley & Sons, New York, 1992). 12. The September/October 1992 issue of Computers in Physics was dedicated to object-oriented in Physics. It contains several interesting articles on the subject. Also, there are several interesting articles in the Proceedings of the First Annual Object-Oriented Numerics Conference, Rogue Wave Software Inc., Corvallis, Oregon, 1993 (unpublished). See also, M.K.W. Wong, K.G. Budge, J.S. Peery and A.C Robinson, Computers in Physics 7, 655 (1993). 13. There is a C version of the popular book on Numerical Recipes originally written in Fortran, W. Press, S. Teukolsky, W. Vetterling and B. Flannery, Numerical Recipes in C (Cambridge University Press, New York, 1992). Also, there is a book on numerical methods in C++, J. T. Smith, C++ for Scientists and Engineers (McGraw-Hill, New York, 1991). See also, L. Baker, C Mathematical Function Handbook (McGraw-Hill, New York, 1991). 14. A few examples from the recent literature: Dirac gamma matrices, four-vectors, complex numbers, ... and other user defined types are employed by L.G. Larsson and E. Nilsson, Computer Physics Communications 74, 41 (1993). A C++ rational number type is heavily used by O. Piro, N. Buric and I. C. Percival, Phys. Lett. A165, 320 (1992). 15.Dyad Software, Bellevue, WA. M++ Class Library, 1991. 16 Rogue Wave Software, Corvallis, OR. Math.H++ Class Library, 1991; Rogue Wave Software, Corvallis, OR. LINPACK.H++ Class Library, 1991 17.K. Gorlen, S. Orlow and P. Plexico, Data Abstraction and Object-Oriented Programming in C++ (J. Wiley & Sons, New York, 1990). The NIHCL can be acquired via anonymous ftp from [128.231.128.7] in the file pub/nihcl-3.0.tar.Z. 18. J. J. Dongarra, R. Pozo, D. W. Waker, An Object-Oriented Design for High Performance Linear Algebra Distributed Memory Architectures, in Proceedings of the First Annual Object-Oriented Numerics Conference, Rogue Wave Software Inc., Corvallis, Oregon, 1993 (unpublished) 19. M.K.W. Wong, K.G. Budge, J.S. Peery and A.C. Robinson, Computers in Physics 7, 655 (1993). See also, M.K.W. Wong and H.E. Fang, MatResLib: A Reusable, Object-Oriented Material Response Library, in Proceedings of the First Annual Object-Oriented Numerics Conference, Rogue Wave Software Inc., Corvallis, Oregon, 1993 (unpublished) 20. K.M. Bitar et at., " The HEMCGC Collaboration", Phys. Rev. D42, 3794 (1990); Phys. Rev. Lett. 65, 2106 (1990). S. Aoki et al., " The QCD Teraflof Collaboration", Int. J. Mod. Phys. C2, 829 (1991). 21. A.G. Willis, M.P. Healey and B.E. Glendenning, The AIP++ N-Dimensional Array Classes, in Proceedings of the First Annual Object-Oriented Numerics Conference, Rogue Wave Software Inc., Corvallis, Oregon, 1993 (unpublished). 22. W. Y. Crutchfield and M. L. Welcome, Object Oriented Implementation of Adaptive Mesh Refinement Algorithms, in Proceedings of the First Annual Object-Oriented Numerics Conference, Rogue Wave Software Inc., Corvallis, Oregon, 1993 (unpublished). 23. There are several articles on distributed objects in recent issues of Distributed Computing Monitor and most computing journals. See, also, A. Yonezawa and M. Tokoro, ed., Object-Oriented Concurrent Programming (MIT Press, 1987). 24. W. Joosen, S. Bijnens and P. Verbaeten, Object Parallelism in XENOOPS, in Proceedings of the First Annual Object-Oriented Numerics Conference, Rogue Wave Software Inc., Corvallis, Oregon, 1993 (unpublished). 25. See e.g., J.B. Weissman, A.S. Grimshaw and R. Ferraro, Parallel Object-Oriented Computation Applied to a Finite Element Problem, in Proceedings of the First Annual Object-Oriented Numerics Conference, Rogue Wave Software Inc., Corvallis, Oregon, 1993 (unpublished). 26 Some workers are beginning to experiment with frameworks in scientific computing. See, e.g., R.A.. Ballance, A.J. Giancola, G.F. Luger and T.J. Ross, A Framework-Based Environment for Object-Oriented Scientific Codes, in Proceedings of the First Annual Object-Oriented Numerics Conference, Rogue Wave Software Inc., Corvallis, Oregon, 1993 (unpublished). 27. Vector, a Newtonian physics simulation framework, is an interesting project which illustrates how to built simulation frameworks. Vector, Emergent Behavior, Palo Alto, CA. 28. MacApp libraries of reusable code can be employed, for example, to design complex computer graphics windows and views. See, David Wilson, Larry Rosenstein, and Dan Shafer, C++ Programming With MacApp (Addison-Wesley, Reading, MA, 1991). Frameworks for event-driven simulations are discussed by Adele Goldberg and David Robson, Smalltalk-80, The Language and its Implementation (Addison-Wesley, Reading, MA, 1983). For frameworks for Neural Networks in C++, see Adam Blum, An Object-Oriented Framework for Building Connectionist Systems (John Wiley & Sons, New York, 1992). Copyright © 4/17/94 Taligent, Inc. All rights reserved. 10201 N. De Anza Blvd., Cupertino, California 95014-2233 U.S.A. Printed in the United States of America. This paper is copyrighted. Under the copyright laws, this paper may not be copied, in whole or part, without prior written consent of Taligent. RESTRICTED RIGHTS LEGEND: Use, duplication, or disclosure by the government is subject to restrictions as set forth in subparagraph ©(l)(ii) of the Rights in Technical Data and Computer Software clause at DFARS 252.227-7013 and FAR 52.227-19. TRADEMARKS: Taligent and the Taligent logo, are registered trademarks of Taligent, Inc. All other trademarks belong to their respective owners ![]()
|
![]() |
![]() |
About IBM | Privacy | Legal | Contact |