Computer Simulation of Quantum Mechanics - Porthouse
The name of this file is OOP.TXT

(C) 1996 David T.C. Porthouse. Copies of this text file may be made for bona
fide non-profit purposes of education or research. These copies may be made
either Internet to client computer, or subsequently from one client computer
to another. All other rights are reserved. David Porthouse asserts the moral
right to be identified as the author of this work, and of any quotation from
it. This work is not produced with the intention of making profits for the
author, but if anyone else ("the user") uses it for a profitable purpose,
then 50% royalties are due on gross profit, and the expense of providing an
Account of Profits under English Law will be borne by the user as an expense
against gross profits. The user will bear the expenses, including travel and
subsistence, of any solicitor, barrister or chartered accountant employed by
the author and engaged in the pursuit of the author's rights.




                     OBJECT-ORIENTED PROGRAMMING for PHYSICS

   In VALLEN.BAS you will find a computer simulation of the motion of an 
electron in a dipole magnetic field. This simulation can demonstrate the form
of the Van Allen Belt as the electron gets trapped in a kind of magnetic 
bottle, with a drift to one side so that eventually its trajectory encircles 
the Earth. To the author's knowledge, Norwegian physicists such as Carl 
Stormer were the principal pioneers of this subject.

   From Norway also comes the SIMULA programming language, which is the 
ancestor of the 'object-oriented' programming languages which we know today. 
SIMULA and languages like it are ideal for the problem of the motion of an 
electron in a magnetic field, because we can start with code like

TYPE  VECTOR  =  RECORD  X, Y, Z : REAL ;   {this is written in quasi-Pascal
                                              or quasi-Modula style}

VAR   VELOCITY, MAGNETICFIELD, ACCELERATION : VECTOR;
      E, M, DT: REAL;

FUNCTION ADD (A, B: VECTOR): VECTOR;
ADD.X := A.X + B.X;
ADD.Y := A.Y + B.Y;
ADD.Z := A.Z + B.Z   END ADD;

FUNCTION SCALE (A: VECTOR; B: REAL): VECTOR;
SCALE.X := A.X * B;
SCALE.Y := A.Y * B;
SCALE.Z := A.Z * B   END SCALE;

FUNCTION CROSS (A, B: VECTOR): VECTOR;
CROSS.X := A.Y * B.Z - A.Z * B.Y;
CROSS.Y := A.Z * B.X - A.X * B.Z;
CROSS.Z := A.X * B.Y - A.Y * B.X   END CROSS;

FUNCTION DIPOLE (POSITION: VECTOR): VECTOR;
{magnetic dipole field as function of position}
      
and then

MAGNETICFIELD := DIPOLE (POSITION);          
ACCELERATION := SCALE (CROSS(MAGNETICFIELD,VELOCITY), E/M);
VELOCITY := ADD (VELOCITY, SCALE (ACCELERATION, DT);
POSITION := ADD (POSITION, SCALE (VELOCITY, DT);       {this is a simplified}
                                                        {integration method}   
                                                           {see note (a)}

This is just the sort of programming that SIMULA was designed to handle. Note
that ISO Pascal could not do the job, because it would founder over the

FUNCTION ADD (...): VECTOR;

declaration. ISO Pascal only allows functions to return standard types
(INTEGER, REAL etc..),  which is rather like having a natural language where
nouns can only be used with the verb 'to be' and verbs can only be used with
pronouns. Many actual implementations of Pascal do allow this type of 
function declaration, which is just as well since it rather defeats the point
of Pascal not to allow it.

  One drawback of SIMULA was the lack of separate compilation in the original
implementation. If we tackle the list given in RAINYDAY.TXT, we are likely to
see functions like ADD, SCALE and CROSS so often that it would be nice if we 
could put them into a separately-compiled module, compile them once and then 
just forget about them. Separate compilation units did appear in UCSD Pascal,
but with the same drawback as ISO Pascal that functions could not return 
VECTOR types as results. The language that really went to town on the idea of
separate compilation was Niklaus Wirth's Modula-2. With Modula-2, we can 
write

FROM VECTORS IMPORT VECTOR, SCALE, CROSS;

or better still just

IMPORT VECTORS;

and we now have full three-dimensional programming facilities built-in to our
language. FORTRAN allows us to use complex numbers, which we could also add 
to Modula-2, but now we can also use a host of objects such as T-matrices,
4-vectors, quaternions, spinors and bispinors.

  Once our module to deal with vectors is set up, we do not need to know its
internal details. It probably uses Cartesian co-ordinates, but a Cartesian
module could be replaced by a module using spherical co-ordinates without us
being any the wiser. Such an approach is known as 'abstract data type'
programming. We define the data type and its operations, and do not worry 
about the detailed implementation. To some extent the abstract data type was
anticipated by all the vector identities such as

                       A x (B x C)  =  A.B C - A.C B

which are independent of co-ordinate system. Dirac, in the derivation of the
equation which bears his name, also introduced the notion of the abstract
data type some time before any electronic computers were in operation. He 
first postulated algebraic entities with certain properties and then worked 
out a matrix representation of those entities in back-to-front fashion. The
derivation of the Dirac equation can look puzzling at first, but once it is
realised that abstract data types are in use then everything becomes clear.

  An amalgamation of SIMULA and Modula-2 might look like the ideal 
programming language  (it's called Modula-3 and there is even Son of Modula-3
called Oberon)  but in practice people stuck with their Basics, Cs and 
Pascals and just upgraded them. We now have Borland Turbo Pascal with Objects
which can do the job, supporting separate compilation, functions which return
vectors and all the other features of what is called object-oriented 
programming. Turbo Pascal is easier for beginners to learn, Modula-2 having 
the drawback that you tend to need to know the whole lot before you can use 
any part of it, and the whole lot can be quite baffling at first. Modula-2 
was the first modern language which the author taught himself (in 1983) with 
the aim of doing three-dimensional aerodynamics computations, and proved to 
be very difficult to learn at first. If the author did not have the example 
of vectors continually in mind, it would probably have been impossible. Now 
he tends to think in Modula-2 while writing in some other language. The
ability of the language to hide information makes it interesting from a
thermodynamic and quantum mechanical point of view.

  Our heart might be in SIMULA or Modula-2, but in practice we will need to 
use other languages, depending upon what is available or what our colleagues 
use. Most people have a Microsoft QBasic interpreter available somewhere. 
Either they got it free with MSDOS 5.0 or it is part of their QuickBasic 
system, which comprises an interpreter and compiler in tandem. This is the 
language which is preferred for the moment if we want to publish anything 
that large numbers of other people can run and understand (see note (b))
using basic equipment.

  We could also just upgrade Basic. Microsoft QuickBasic 2.0 allows separate
compilation, but not records. QuickBasic 4.5 allows the use of records, but 
not functions which return records as results (nor does Visual Basic for 
DOS). Perhaps someday we will have a QuickBasic 5.0 or a Visual Basic for 
DOS 2.0  (see note (c)) which allows us to write

FUNCTION SCALE (A AS REAL, B AS VECTOR) AS VECTOR

In the meantime, it is possible to add something like object-oriented
programming to QuickBasic 4.5, as described in note (d).

  In DIRAC.BAS, which you can download, you will find things done the hard 
way because this program was originally written in QuickBasic 2.0. There you 
will see a four-real-component wave function written out component by 
component. The author has converted this towards object-oriented programming 
style, and the result is to be found in DIRAC2.BAS which is a continuing
project. VEC4.BAS, to deal with the electromagnetic 4-potential, and
DWAVEF.BAS, to deal with the Dirac wave function, are the separately-compiled
modules which support DIRAC2.BAS.

  In DIRAC2.BAS we have a representation of the group U(1) (is this 
correct?). Suppose that we also program the groups SU(2) and SU(3). It is 
believed that we can just use the object-oriented programming concept of 
'inheritance' to form the group  SU(3) x SU(2) x U(1)  rapidly and without 
error. The author would be grateful for other people's comments on this 
point. Has he got it right?  At the point where we code SU(2), we will 
probably have outgrown QuickBasic 4.5, and it will be time to switch to 
Borland Turbo Pascal or to C++/JAVA. There is nothing to stop you 
anticipating this and getting modules published on the Internet now!

  Someday, every school or college physics department in the world ought to
have something like a hexium computer running a simulation of quarks, W and Z
particles or Higgs bosons, in natural succession to the simulation of the
electron in DIRAC.BAS which anyone can now download from the Internet. Then 
it should get easier to persuade the taxpayer to part with large sums of 
money to finance the construction of new and more energetic particle 
accelerators, both to investigate higher-energy regimes and specifically to 
look for the Higgs boson. Particle physics has the reputation of being an 
esoteric subject, but it doesn't have to be with some computer simulations 
based on object-oriented programming. A picture of the proton drawn as three 
coloured balls is frankly puerile, while loads of mathematics to describe 
quantum chromodynamics is too much for most people to digest. A computer 
simulation showing quarks in action is just right:  you can look at the red, 
green and blue wave functions which you see on the screen, or if you want to 
go deeper, you can look at the source code of the modules which make up the 
program (note (d)). You get a choice. Then if we ask you for a very large 
sum of money for our next experiment, we are not insulting your 
intelligence, because in honour, we did everything we could to show you how 
we were spending your money.

  What has been written here is intended to give you an idea of the
possibilities and problems associated with object-oriented programming and
physics. Nothing here is the last word on anything, and if you know anything
which the author does not, then please let him know!



NOTES

(a) We showed a simple Euler method of doing the integration in the case of 
the electron. In practice we would use a reversible method such as the 
improved Euler method or the central difference method. Reversible methods 
tend to respect the workless character of the force acting upon the electron 
or the couple acting on a spinning top or gyroscope. You will find that they 
go naturally with three-dimensional programming.
   Once we have a reversible algorithm in operation, then in the author's
opinion we will need to add some explicit randomness in order to get entropy
production. This is one reason why the author is looking at the addition of
randomness to DIRAC2.BAS, where he is investigating something like tachyonic
Brownian motion. In the case of a numerical simulation to demonstrate
Boltzmann's H-Theorem, we could just add ordinary Brownian motion on the 
scale of Planck's constant to give a rough-and-ready representation of 
quantum mechanical effects.

(b) If you want to follow the author and write software for QBasic, you may
wish to acquire your own QuickBasic 4.5 compiler. This is to be preferred to
its successor product Visual Basic for DOS for the sake of compatibility with
QBasic. If you can only get hold of Visual Basic or if you have it already,
try getting a book on QBasic or QuickBasic 4.5 and then treating Visual Basic
as the older product. Alternatively, get a book such as Dr. James W. Cooper's
Visual Basic for DOS ([1]) where the first part of the book teaches standard
Microsoft Basic before dealing with 'Visual' features which you do not want 
in this context.
   
(c) Obviously with any QuickBasic 5.0 we would like support for SVGA to give
us a better view of the electron in the Van Allen Belt. We would also like a
frame buffer for VGA and SVGA for when we write programs like a relativistic
flight simulator. At the moment we can only use the frame buffer with EGA.

(d) Suppose that we wanted to represent the vector assignment

                          A :=  B x C  +  D x E

We might like to write this in algebraic style as

                          A :=  B * C  +  D * E

where we would define 'overloadings' of the standard operators + and * in 
order to deal with vector operations. In ADA this would look something like

    overloading '+' (A,B:vector):vector;          {This may not be accurate!}
    var plus:vector;                              {Please E-mail if you know}
    begin plus.x := A.x + B.x;                    {what it should look like.}
          plus.y := A.y + B.y;
          plus.z := A.z + B.z;
    return plus end;

In many languages we would have to settle for functional style

                      A := ADD(CROSS(B,C), CROSS(D,E));

which isn't too bad. In ISO Pascal we would define TEMP1 and TEMP2 as vectors
and work in a 'high level assembly language' (HLAL)

    CROSS(B,C, TEMP1);                     {multiply B and C giving TEMP1}
    CROSS(D,E, TEMP2);                     {   "     D  "  E   "    TEMP2}
    ADD(TEMP1,TEMP2, A);                   {add TEMP1 and TEMP2 giving A}

This is hardly ideal but it is still better than just writing everything out
'longhand'. In Microsoft QuickBasic 4.5 and Visual Basic for DOS we are
apparently committed to HLAL style as well, but there is a REDIM PRESERVE
feature which could be used to manipulate an array of vectors.  A ... E would
be positive integer pointers to particular elements of this array. We would 
create B ... E with statements like

    MAKEVECTOR B, CARTESIAN(1,2,3)              {B.x = 1   B.y = 2   B.z = 3}

and reserve storage for A with

    NEWVECTOR A

and then

    ASSIGN A, ADD(CROSS(B, C), CROSS(D, E))

where ASSIGN is a subroutine written by us. Negative integers would point to
a second temporary array which would be ERASEd at the end of the ASSIGN
subroutine. Operations like CROSS and ADD would return negative integer
pointers as values. If we obtained an upgraded version of Visual Basic which
did allow functional style, then it would be easy to change our program
accordingly. ASSIGN would be redundant, but easily edited out, or just left
in out of laziness. NEWVECTOR would not be redundant since it also fills the 
vector with zeroes. We can in fact retrofit this idea to QuickBasic and this 
has been done with GRAV.BAS which you can download. This method is also in 
use in DIRAC2.BAS, DWAVEF.BAS and VEC4.BAS.
   One curious advantage of QuickBasic 4.5 and Visual Basic for DOS is the 
fact that the user program can be in interpreted form, but the module to 
handle vectors can be compiled into a library. This looks a very useful 
feature when we come to upgrade DIRAC.BAS, since we are likely to do a lot of
tinkering to get things right, but the module DWAVEF.BAS, which does the 
number-crunching on the Dirac wave function, won't change so much, and can 
therefore be compiled once and for all.

REFERENCES

[1] Dr. James W. Cooper, Visual Basic for DOS, subtitled Building Scientific
and Technical Applications, John Wiley, New York 1993, ISBN 0-471-59772-4. 
The first seven chapters of this book could just as well be an introduction 
to Microsoft QBasic or QuickBasic 4.5, except that REDIM PRESERVE and 
CURRENCY types are not recognised (you would soon find this out anyway). The 
'Visual' features are sensibly introduced later. This book has a variety of 
useful code, such as code to access the mouse or to do matrix inversion and 
eigenvalues. 

CLICK ON "BACK" OR "BACKWARD" TO RETURN TO THE PREVIOUS PAGE
______________________________________________________________________________

This author's website is

http://ourworld.compuserve.com/homepages/anima/quantum.htm

His e-mail address is 

100425.3501@compuserve.com

Fellow CompuServe subscribers may of course contact him on 100425,3501