readme

人工智能的matlab程序

class that is used to do that magic, so the code in World.m is much easier to read. 
There is much less low level math floating around.

-------original readme follows
This is the port to Swarm of the original NeXTstep version of
the Brian Arthur, John Holland, Blake LeBaron, Richard Palmer, and
Paul Tayler Artificial Stock Market.  The port was done in the Summer
of 1996 and has been updated to include some recent adjustments in
Swarm in the Summer of 1997.  Regardless, there are a number of Swarm
advancements (e.g., EZGraph) that have not been utilized in the
current code.  It does include, however, the much needed and
appreciated -batchmode option.
	The port is a slimmer version of the original done in straight
Objective-C for the NeXTstep platform.  There is a non-graphic version
available from the authors, but the Swarm version should satisfy most
given the ease with which it can be altered.  The port was done by
Brandon Weber, a 1996 Summer intern.  For questions regarding the
Swarm ASM he can be contacted at [e-mail].  All other
questions regarding the original version, specific aspects of the
model, or published works should be directed to Richard Palmer at
[e-mail].
	It should also be noted that this version includes only one
type of agent, the BFagent (bit forecasting agent), which learns via a
classifier system of John Holland.  It also has a built in Genetic
Algorithm.  Brandon Weber developed another agent, which learns using
an Artificial Neural Network.  The ANN itself is very simple, but
comparisons between the agent types are interesting.  The original
NeXTstep version contained several other types, all considerably more
simple-minded than the BFagent.  Part of the goal of this simulation
is that users develop their own agents.  For those who wish, they can
contact Brandon Weber for information on adding an agent (or for the
code that includes the ANNagent).  It is not difficult and only
requires additions to a select number of places in the code.
	I include a brief explanation of each of the programs modules.
This is by no means even remotely extensive, but should give some
sense of where things happen in the dense world of the ASM.  First it
would be wise to briefly explain what happens in the ASM.  Agents are
trading one asset but have the option of placing their money in what
is basically a bank account with a riskless return.  The agents make a
decision in each trading period how much to buy and sell based on
their prediction of the next period's price+dividend.  The dividend
process is AR(1) and the trading is managed by a Specialist that
attempts to match buys and sells.  How an agent predicts depends on
what type of agent it is.  As was mentioned, this release carries only
a bit-forecasting agent.  For specifics on the mathematics of the
asset model, one must see the published works of the above authors.  A
book is coming out shortly with the main paper on this simulation.
Contact Richard Palmer.  With that, the different objects are as
follows.

1) The Agent superclass (a swarmobject) has elements that all agent
types will have.  The BFagent is of type Agent, and any new agent that
might be developed would also be of type Agent.  This module includes
variables such as demand, initialcash, etc. and member functions such
as -prepareForTrading, -setInitialCash, +setAgentWorld, etc.  Since
all agents in this world are trading an asset, they all have these
types of functions and variables in common.

2) The BFagent is super complex.  Most of this code has not been
changed to be more Swarm friendly than the original version.  To
understand this agent you are encouraged to look at the published
material of the above authors or to direct specific questions at
Richard Palmer or Brandon Weber.  Basically each agent has a number of
equal in length bit-vectors of technical trading rules (where one bit
might be the rule, say, price is greater than the 20-day moving
average of price).  In other words, each vector represents some
collection of rules that a real trader might use.  In each trading
period these rules are compared with the world's bit-vector, which
includes all the possible trading rules.  The vectors that have all
its rules matching-up with the state of the world are considered
candidates for use in predicting price+dividend.  The one that has
been most successful in the past (i.e., has been able to best predict
the price+dividend) is used.  Over time the rules are morphed via
Genetic Algorithm and in turn better vectors are developed.

3) The World holds the big-bad bitvector of rules.  In turn it also
holds information on dividend (despite the fact that the Dividend
object generates the dividend payment) and price (despite the fact
that the Specialist object works to establish the price).  Whenever
the dividend is generated and the price is reached in a period the
World is given that information and it's its to keep for eternity.

4) The Dividend object simply controls the AR(1) process that
generates dividend payments.

5) The Specialist negotiates the trading of the asset. There are three
types of Specialist: the RE Specialist, or Rational Expectations
Specialist, the SP Specialist, or Slope Specialist, and the ETA
Specialist, or ETA Specialist (I forget the meaning of ETA, but it
will be explained).  The RE Specialist is meant only to check whether
this simulation will reach the typical Rational Expectations
equilibrium.  One point of this whole project is to check whether
seemingly real world behavior can be endogenously generated by
granting sufficient heterogeneity to agents that are based on a RE
framework.  But for this to even be testable the agents (when made to
be homogeneous) should come to a RE equilibrium.  The RE specialist is
used only for this purpose.  No matter the Specialist, each agent
reports to the Specialist how much it intends to buy, sell, or sell
short.  The RE specialist simply equalizes supply and demand should
they be different.  As a result the boring behavior we expect arises.
The SP Specialist also receives from the agents the slope of their
demand curves.  In turn the Specialist knows how to change the price
to best equalize supply and demand and can do this in one or two
iterations.  The ETA specialist changes the price using a parameter
incidentally called eta.  In each trading period there are several
iterations of this adjustment process until the difference between
supply and demand is sufficiently small.

6)  The ASMModelSwarm orchestrates this magic.  

7) The ASMObserverSwarm puts pretty pictures on the screen.  Note that
you have the option of printing all the graphs as well as writing data
and the simulation parameters.  To write the data you must click on
the -writeData button before the simulation begins or else nothing
will happen.  You can click on the -writeParams button at any time.
The parameters and data are written to a time-dated param.data and
output.data file respectively.  Note that the default setting for the
random seed in the window where you can set the parameters is zero.
This means that the seed is randomly generated.  If you want to repeat
a run you must write the params and use the random seed that you find
in the param.data_somedate_sometime file.

8) The writing of data and parameters is controlled by the Output
module.  Output knows learns the parameters in the ASMModelSwarm.  It
learns the price, dividend, etc. from the World.

9) ASMBatchSwarm controls the batch stuff.  To run just type 'asm
-batchmode'.  Note that to do this you need a batch.setup file which
includes the loggingFrequency and the experimentDuration.  These are
also set in the ASMBatchSwarm itself but can be changed in batch.setup
without recompiling.  The file that loads in the parameters is called
param.data.  When you click on -writeParams running in GUI mode the
file param.data_somedate_sometime is in the proper format to be a
param.data file that is loaded in batchmode.  In turn you can just
move param.data_somedate_sometime to param.data and you're good to run
the same simulation again in batchmode.  Also, when you run in
batchmode parameters and data are written to their respective
time-dated files automatically.

10) Random is one unfortunate holdover from the old version.  Last
summer (1996) there was not a double random generator so I stuck to
the original NeXTstep version's.  Now Swarm has one but I didn't have
time to make the changes.

11) Main is main.  You might wonder why the parameter writing is done
in here.  It is because this is the only way to assure that the params
are written at the end of the simulation.  This is done for two
reasons.  One is that the params can conceivably change throughout a
simulation and in turn they should be written at the end.  Second, of
you click on -writeParams before you say -go, it is also before an
instance of the object Output has been created.  Output must exist for
the params to be written.

This is cursory at best, but you are all probably better people than
me, so you can figure the rest out with the help of some strategically
placed questions to either Palmer or Weber.  Enjoy.