Just in case anybody is interested in the idea of playing with computer models of the stock market, or anything else (for any reason) -I thought I'd offer a few tips or pointers:


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 way!"......

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).

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 potential possibilities).

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".

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).

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 the programme.

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.

 -What are the relevant characteristics our "Stocks" will be required to exhibit?

 -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, etc.).

 -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).

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).

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:

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, procedural, system.....