Just in case anybody is interested in
the idea of playing with computer models of the stock market, or
(for any reason) -I thought I'd offer a few tips or
To be honest, I have no real experience of modelling real-life
processes with software -howver, my experience as an artist suggests
that it is often rewarding (and fun) to try doing things which one has
no idea how to do -and to learn by seeing how it all pans out.
Afterwards, one can join the "Sinatra Club" -and claim "I did it my
I'm sure there are many books on how to build (and implement) dynamic
real-time simulation systems -if anyone has this knowledge, then
perhaps they could pass on any tips or advice that they might have.
The first step in constructing any
model, is to develop a "Meta-System" (Ontology) -i.e. The conceptual
building material which will be used to construct the model. To a
certain extent this is defined by the programming language used -but it
is also open to a wide range of conceptual variation (just as writing
in English, as opposed to any other language, imposes some restriction
but doesn't prevent one writing in an ironic, romantic, logical or
fantastic style -or from writing fiction or non-fiction -or something
somewhere in between).
A World of Objects?
Because we are feeling our way -all definitions will be minimal (in the
initial phase) and can be tightened up afterwards as the need arises
and as more experience becomes available. This is part of a deliberate
design strategy called "prototyping" -which is pretty useful for
creative systems -because one simply starts (somewhere) and then keep
on refining the system until it becomes perfect, one gets bored, the
money runs out -or all those involved die of old age......
Such an approach may never deliver a finished product (which may be
upsetting for those hoping to use this product for some practical,
commercial(!), use) -but it does offer lots of oportunity for
experimenting with different modifications (until we drown in a sea of
The Universe of the Market:
For a (possible) stock market model,
I'm thinking of a simple "object orientated
" approach -i.e. there are
"objects" that have certain characteristics (either fixed or static)
and there are "methods" for changing the value of the characteristics
that are variable.
-For example, a "dog" has the characteristic "tail". All dogs have
tails (even if it has a length of zero). If it is a puppy, then the
tail size may increase (but usually not decrease) usually proportional
to the body size. However the "state" of the tail might vary "high",
"low", "medium" or "wagging" -by implication, there would be "methods"
(like "offer bone" -or "get whip") which would determine the "state" of
the tail. In principle, a whole bunch of dogs would behave in the same
way (although there may also be some individual differences -zero tail,
perhaps -or "nervous" maybe). In order to distinguish each individual
dog from its fellows (and from its Platonic original) each dog has its
own unique name.
Presumably, the "Market" contains two types of "object" -i.e. "Stocks" and "Buyers".
Defining the Components -Generally:
Clever observers may notice that there is an important distinction
between them -one is "passive" and the other is "active". "Buyers"
usually buy "Stocks", but presumably, "Stocks" do not often do much to
"Buyers" (except make them happy or sad).
At present we have no idea how important this distinction may be (or
even if we wish to maintain it -perhaps it would be fun to allow
"Stocks" to do strange things to "Buyers", things like eat up "Buyers"
houses, or persuade their partners to leave them. However at present we
do not even know if "Buyers" have houses or partners).
Defining the Components -Specifically:
At this stage, we will need to define
the characteristics that "Buyers" and "Stocks" have -and the mechanisms
that define their interactions.
In principle, we only need to define one example of each of our
component objects -we can reproduce and name the individual examples
when the programme actually starts running. By "name" we simply mean an
identifier that allows us to know which individual we are referring to.
A range of names such as B1 to B20 would be fine for the Buyers and S1
to S350 would be ok for the stocks -depending on how many of each we
decide to use. These numbers can also be filled in when we actually run
However, we might need to decide (at some stage) if either Buyers or Stocks are aware of their own name (identity
Probably, we shall also need to have some way of linking Stocks to
their "Owner" (i.e a Buyer who has purchased a specific stock) -if this
is relevant, within the model being developed.
Although the principle of "ownership" is assumed to be a basis
principle of the market -some statistical models (perhaps involved with
"price" fluctuations) might ignore "ownership" completely.
Creating the Prototype:
-What are the relevant characteristics our "Stocks" will be required to exhibit?
(price, owner, ect.)
-What are the relevant characteristics our "Buyers" will be required to exhibit?
-Presumably, we shall also require some system (or procedure)
which allows the Buyers to buy (and register) their stocks. Should this
be a separate "Object" (ie. "Clearing-House" -with which
characteristics?) or could these procedures be seen as
"characteristics" of either Buyers or Stocks?
-Presumably, we shall also require a set of "conditions" (or
stimuli) which will trigger certain actions by the Actors (i.e. the
active objects within our model). Once again, we must decide if these
are represented by an external "object" (Market-Conditions,
General-Economy-Conditions, etc.) or internal variables, within the
Buyer ("profit-loss", "security-of-tenure", etc.) or within the Stock
(price-direction, absolute-price, price-relative-to-something-else,
-As part of the process of defining the above Objects and
Characteristics, we would need to specify initial values for every
variable. These can either be specified in the programme (so they will
be the same every time the programme is run) -or we can specify that
this information is provided (in some way) when the programme is/starts
running, thus introducing the possibility of testing the programme
under different conditons (for example, too many or too few Buyers
-few, or many, Stocks available, etc...). For some systems, the
starting position may be critical to how the system susequently behaves
(imagine the difference between a human baby, born on the streets or
born in a palace!).
-We shall also need to have some kind of "representation system"
which will allow us to "visualise" (express or quantify) the state(s)
of the variable conditions within our system. Presumably, there is
little point in our "stock market" working like crazy, but completely
invisible, somewhere deep inside our computer. Strangely enough,
constructing and implementing this "representation system" may well be
the most taxing (but rewarding) part of the design process.
Once the above questions have been
answered, the next step is the (reletively easy) step of translating it
into syntactically correct code (i.e. a compound statement grammaticaly
acceptable to the relevant programming language parser).
Testing the Prototype:
Once the model has been translated into
syntactically correct code we can run the programme and see if it is
also semantically correct (i.e. does it conform to our ideas/wishes).
Modifying the Prototype:
Having seen what our programme actually does when actually implemented and run on a computer -we are faced with several options.
Under practical (commercial) conditions, our choice of action will
probably be restricted by the way the programme actually behaves and
the way the customer wishes it to behave. Under artistic or scientific
(messing around) conditions we are free to do whatever we wish (or find
interesting, or concider relevant).
In principle, the above conditions may (or may not) determine which of
the options we are forced to accept (so they are no longer options)
-however, in principle, we have a choice between:
a -Running the programme again with
different input variables (if available) in order to test its behaviour
under different conditions.
b -Modify something in our programme (for example, the value of some
initial variable(s) or perhaps some of the conditions) -iether simply
for the fun of it, to see if this has a fundamental (i.e. noticeable!)
effect on the way the programme runs (possibly influencing our concept)
-or because the prorgramme is not working properly (according to some
set of syntactic or semantic criteria).
c -Modify something in our concept (for example, invent an extra
object, condition or procedure and code this into the system) to see
how this affects the way the programme runs (possibly requiring further
modification to the programme because it is no longer syntactically (or
even semantically) correct.
d -Give up and go to bed or sell the finished programme to somebody......
One may notice that I have tried to
specify how we can construct a model, without actually specifying how
this model should actually function in practice. Of course many people,
including myself -like to talk about things, without knowing anything
about what it is they are talking about.
However, I belive one (sadly neglected) social value of computer
programming (as an intellectual discipline) is that it offers ways of
thinking which are both very abstract and very precise (I love
paradoxes too. How stupid western culture is, not to believe in them,
except as proof that something is wrong!).
I guess we all have our little foibles. When I was at school I found
learning all those awful mathematical tables a complete and utter bore
(and a hopeless task which I never achieved). Then one (happy) day, we
were introduced to "algebra" -suddenly I found this increadibly
exciting -the idea that one could play with (mysterious) objects
without knowing what they were......
Now I am more aware of the dangers of believing in abstractions which
have become totally divorced from any functional reality -but perhaps
this understanding has only developed through the practical experience
gained by trying to map abstract concepts into some kind of specific,