I've done some tentative impure requirements analysis for a simulation
of the world economy. I say impure because I can't get design ideas
out of my head. It is probably best to admit this up front and also
to hint broadly at what these design ideas are.
Currently I envision this project as implemented by a relatively
simple program and a much more elaborate database containing a lot of
carefully selected data. By 'database' I mean a collection of named
files, probably bound together by a common base name and distinguished
by distinctive extensions.
The system that I envision is something like a spreadsheet that loops
through a series of records making changes by applying certain rules
which are also stored in these records, and indeed could be
implemented as a spreadsheet, though I probably won't implement it as
one. If you are in doubt about what I have in mind, try thinking of
this as a spreadsheet and you probably won't be too far wrong.
(Indeed, use of a spreadsheet for rapid-prototyping may be wise.
People comfortable with spreadsheets may want to play around with
this a bit, to see what is possible.)
Ordinarily a spreadsheet loops though all fields (columns) of all
records (rows) and does whatever updates are necessary as they are
encountered, but no more than once per loop. That is not behaviour
that a large scale economic model should use, because it would involve
updating some records too often.
What I have in mind could be thought of as a spreadsheet in which each
record has a first field which is countdown timer, changed once per
iteration, and all other data fields in the record have an implicit
"and timer=0" condition, so they are only updated when the timer
counts down to zero -- the timer itself resetting by coping its
initial value from another field the iteration after it reaches zero.
As I envision it, the program loops though a series of records in a
database, reading and updating them according to "instructions" also
contained in that database. By 'instructions' I don't mean computer
programs but just important data values and limits, or symbolic
expressions, such as could be represented in any cell of a
spreadsheet.
As I see it, a few of these instruction are hardly ever changed, and
in fact cannot be changed without going through several steps of
supplying appropriate passwords. Included in this list of special
instructions are flags or values stating which instructions fall into
this class, and which may be more easily modified. Some other
instructions are (therefore) more easily modified but can only be
changed by the operator, and a few more instructions can be modified
by a running program.
Broadly speaking I think there will be two main classes of records:
1. Population-geographic units, representing a region of the earth
or a population-cohort (or, ultimately, a single individual).
2. Information-estimation units, which represent a fact or supposed
fact, piece of information or estimate. What I have called
"instructions", values or symbolic expressions central to the
operation of this model fall into this class.
Below I have a list of preliminary requirements, and after some of
them a design or implementation hint based on this quasi-spreadsheet
model.
1. The proposed simulator shall be an open system, available to anyone
who wants it at no cost, in both source code and in binary format,
with documentation, and written in a very popular programming language
so it can easily be installed on almost any system.
2. The simulator shall be data-driven without any hardwired or hardcoded
algorithms other than those of a fundamental mechanism for reading and
updating entries in a database according to rules or instructions
also represented as entries in a database. The term database in this
requirement shall not be interpreted as implying any specific type of
storage or retrieval system, but shall not include anything that
involves changes to the source code of the simulator.
(Symbolic expressions in cells of the (quasi-)spreadsheet would be
considered data, and could be modified, but in general would
be modified rarely and not normally by the operations of the
program.)
3. The simulator shall be capable of generating, saving, copying,
renaming, deleting, and reloading and running any one of several
simulation-datasets and shall have a convenient mechanism for
allowing the operator to choose from amongst a collection of
named simulation-datasets kept in mass storage.
4. The simulator shall be capable of simulating the economic activity
of arbitrarily large geographic regions up to the entire planet
(solar system? !) and arbitrarily small regions down to the size
of a human being, except as limited by disk space or other mass
storage limitations. For the purposes of this requirement economic
activity shall be interpreted as including all exchanges of commodities,
money, and other legal instruments of exchange including electronic
transactions; also all human activities that directly and
significantly effect such exchanges, including physical and mental
labour; communication by request, pronouncements of opinion, or
exchange of information; also human sexual activity and reproduction,
and also all similar activities carried out by machines.
(A record or spreadsheet row could represent a large geographic
region, and in simple models the whole earth, or could represent
a much smaller region like a village. It could represent a
large group of people, like all males, or all young males, or
young males of an ethnic group, or ultimately a single person.)
5. The simulator shall be capable of simulating lengths of time up
to the approximate age of the human species, and down to a lower
limit dependent on the processing speed of the host machine, but
at least as small as one second.
(How long a length of time is represented by the values in one
row of the quasi-spreadsheet would be encoded in the initial
values for the countdown timer, and would be updated from all
other relevent records each time the counter reached zero.)
6. The simulator shall have no built-in limitations on the granularity
or level-of-detail of a simulation other than imposed by machine
disk space or other mass storage limitations.
7. The same granularity or level-of-detail shall not be imposed on
all subsets of a simulation-dataset, some of which may be more
or less detailed than others.
(Region or person granularity would depend only on how many rows
and how much space or number of persons each row respresents.
Time granularity is represented by the initial values placed
in the countdown timers and can be changed by changing the
values in the (semi-constant) fields used to reinitialize the
timers.)
8. The simulator shall be capable of cooperative sharing of data and
processing with other simulations runing on the same machine or on
other machines linked to it through a network or internet.
(It should be possible to include in some "cells" of the
"spreadsheet" a URL representing a file to obtained by FTP,
or a procedure to be run by remote procedure call.)
9. Cooperation with other simulations shall be coordinated or mediated by
very popular protocols, including at least the FTP protocol for
file sharing, and the details of this cooperative activity shall be
specified in a publicly available protocol document that shall not
restrict cooperation to simulations of the same type nor using
the same simulator program.
10. The simulator shall include capabilities for monitoring using video
display or printout, or both, with numerical and graphical
representation or both.
11. The simulator shall include capabilities of halting a running
simulation, manually entering changes, and resuming.
12. The simulator shall include capabilities for rolling back a
simulation to an earlier state and restarting from that point.
13. The simulator shall include a capability for causing a simulation
to fork or divide into two simulations that differ only in
certain fields or entries modified by the operator and can
be saved separately under different names.
14. The simulator shall include a capability for changing the
granularity or level of detail of a simulation on the individual
database record level.
(Space or person-count granularity could be changed by splitting
rows -- duplicating them then making necessary changes to
reduce region size or person counts in each new row.)
15. The simulator shall include a capability for changing the
granularity or level of detail of a simulation globally to
increase or decrease the granularity in space or time or
both of each database record, up or down to the next unit,
except where disk space or processing speed limitations
make this impossible.
(It should be possible to perform a single operation to make
large changes in time-scale over a wide set of rows by
simultaneously changing from daily update to weekly update,
or annual update to monthly. Similarly it should be possible
to make large scale changes in regional or cohort data
by splitting country records into province records or
province records into township records -- etc.)
16. The simulator shall include capabilities for printing out
all data in a simulation or summaries of this data, or
both, and shall also include capabilities for plotting
data or summaries in graphical form.
17. The simulator shall include capabilities for logging all
activity and printing these logs on operator request.
18. The simulator shall include capabilities for entering,
saving, appending to, and printing bug and problem reports,
but shall not allow such reports to be edited or deleted
by anyone except the root or supervisor responsible for
the system.
19. The simulator shall include capabilities for downloading
simulation, logging, and problem reports from another
by requesting it via network on operator request or
according to an operator-prepared schedule, and shall
also include the corresponding capabilities to upload
this information to another machine over the network
if authorised to do so.
This is only a first draft, incomplete and very crude in places,
but it should suggest the general idea. I'd like anyone interested
in this simulation project to look it over and make comments,
preferably to the mailing list as a whole -- so that it will stimulate
more discussion, or to me personally if you prefer. I will try
to save all comments so that at some point they can be archived
together.
dpw
Douglas P. Wilson [EMAIL PROTECTED]
http://www.island.net/~dpwilson/index.html
