Is Schrödinger's Cat
Object-Oriented? - Chapter 5




V. Dynamics: Objects, Messages
And
Feynman Diagrams

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.




JavaTM is a trademark of Sun Microsystems, Inc.

Microsoft, Windows and Windows NT are registered trademarks of Microsoft Corporation.

Other companies, products, and service names may be trademarks or service marks of others.

Copyright    Trademark



  Java Education Java Home  
IBM HomeOrderEmployment