asmmodelswarm.java

ASMUML.zip一个人工股市的建模资料,主要是针对asm2.2的建模,欢迎大家下载

// Java ASM application.
// This library is distributed without any warranty; without even the
// implied warranty of merchantability or fitness for a particular
// purpose.  See file COPYING for details and terms of copying.

//package asmjava;

import swarm.Globals;
import swarm.Selector;
import swarm.defobj.Zone;
import swarm.defobj.SymbolImpl;

import swarm.defobj.FArguments;
import swarm.defobj.FArgumentsImpl;
import swarm.defobj.FCall;
import swarm.defobj.FCallImpl;

import swarm.activity.Activity;
import swarm.activity.ActionGroup;
import swarm.activity.ActionGroupImpl;
import swarm.activity.Schedule;
import swarm.activity.ScheduleImpl;
import swarm.activity.FActionForEach;

import swarm.objectbase.Swarm;
import swarm.objectbase.SwarmImpl;
import swarm.objectbase.VarProbe;
import swarm.objectbase.MessageProbe;
import swarm.objectbase.EmptyProbeMapImpl;

import java.util.LinkedList;



/*"The ASMModelSwarm is where the substantive work of the simulation
  is orchestrated.  The ASMModelSwarm object is told where to get its
  parameters, and then it buildsObjects (agents, markets, etc), it
  builds up a phony history of the market, and then it schedules the
  market opening and gives the agents a chance to buy and sell.

 This model presents an interesting scheduling challenge. We want to
  generate 501 periods of history that agents can refer to when they
  make decisions.  The warmUp schedule is a repeating schedule, and we
  want its actions done 501 times, and when that is finished, we want
  the periodSchedule to begin at time 0, the starting time of actual
  agent involvement.  When I looked at the original, I shuddered at
  the complexity of it.  I thought to myself, there must be a simpler
  way to do this [grin :)], and it turns out there is.  Now, in case
  you are comparing the new code against the old code, understand that
  the old ASM-2.0 way was like this.  First, the warmUp schedule is
  created.  Then a second nonrepeating schedule is created, called
  "startupSchedule."  At time 0 in the model, that startupSchedule
  controls the first action, and the action it executes is a method
  that causes the warmUp schedule to run 501 steps of prehistory. I
  don't know why they had 501 steps, but they did.  That's the warmUp
  method.  The warmUp method gets that done by creating a temporary
  Swarm class without any context (activateIn: nil) and then
  activating the startupSchedule in there, so it runs "doWarmupStep"
  501 steps, but none of the 501 steps count against time in the
  larger context of the model.


  As of ASM-2.2, I have gotten rid of that complicated setup. Instead
  of creating the phony swarm and activating the warmup schedule
  inside it, I created a method in ASMModelSwarm.m that carries out
  one time step's worth of warmup.  And then I dumped 501
  createActionTo methods on the startup schedule that execute the
  required startup steps.  I've verified the results are numerically
  identical to the original model.  And the scheduling is much easier
  to understand.

  After the warmUp, then an ActionGroup called "periodActions" comes
  to the forefront.  The periodSchedule is a repeating schedule, which
  causes the periodActions to happen at every time step in the larger
  model.

  In ASM-2.0, there was another initial schedule called
  initPeriodSchedule.  After looking at it for a long time, I
  concluded it was doing nothing necessary, it was basically just
  running the periodActions at time 0 only. We might as well just
  schedule that action at time 0 in the startupSchedule. I have
  verified that the model runs exactly the same (numerically
  identical).  Now, as noted below, I think this step is logically
  unnecessary, but removing it changes the numerical path of the
  simulation, so I'm leaving it in for comparison.  "*/

/**
 * <p>Title: ASMModelSwarm</p>
 * <p>Description: El ASMModelSwarm es donde se lleva a cabo todo el trabajo
 * de peso. Existe una 鷑ica instancia de esta clase.
 * La instancia de esta clase es asmModelSwarm. Cuando el usuario pone
 * en marcha la simulaci髇, esta instancia recibe los par醡etros, probablemente
 * modificados desde las sondas. A continuaci髇 crea todos los objetos
 * relevantes (agentes, mundo, especialista y dividendo, principalmente)
 * por medio del m閠odo buildObjects(). Una vez creados los agentes, crea una
 * historia ficticia del mercado para que las condiciones iniciales del mundo
 * (por ejemplo la media m髒il de 500 periodos) tengan sentido. Por 鷏timo, hace
 * sonar la campana de apertura del mercado y deja a los agentes que hagan el
 * resto.</p>
 *
 * <p>El programa de acciones del modelo es bastante complejo, aunque lo fue
 * much韘imo m醩 en las primeras versiones del mercado en ObjectiveC. Lo
 * que se persigue es conseguir crear una historia ficticia inicial de 502
 * periodos de forma que cuando los agentes empiecen a negociar dispongan de
 * datos que tengan un m韓imo de sentido. Para conseguir este objetivo se crean
 * dos programas de acciones. El primero, llamado startupSchedule, ser