|
From: Mark R. D. <mdi...@la...> - 2003-07-20 15:08:54
|
I've been trying to get this concept of mapping between Topologies,
Graphs and Spaces a little clearer in my own head. Basically I think it
boils down to the following:
Context:
Simply a Map of existing Topologies based on key "type". Adding a Agent
to the Context actually adds it to all the Topologies that are in that
Context, removing does the opposite.
Topology:
DiscreteSpace, Graph or Other Object that encapsulates the relationships
between a Set of Objects.
1.) I'm concerned about Topologies having "type" defined internally
within them. theres always room for errors where the type in the
Topology may be able to get out of sync with the type it is mapped to in
the context. I recommend removing or internalizing/finalizing this and
only focusing on mapping by the key/value pairs of the Context.
2.) I'm starting to think that a Generic Context could be written into
SimModels (or SimModelImpl/SimpleModel) in such a way that we begin to
define "Context" in terms of its "generic" definition and the way it is
usually applied in the programming community.
For example, in the JSP/Servlet API, Context refers to attribute
"mappings" of various "scopes". ServletContext, SessionContext,
RequestContext are various scopes where attribute mappings can occur,
each has a certain scope of longevity (Servlet the longest -- request
the shortest). There are also usage of Contexts in other Applications;
JNDI/LDAP, Jelly, JXPath, Jaxen, Xalan, Saxon to name a few. Mostly
oriented to Webapplications, I believe this is where the design pattern
originated. In all cases the concept of a "Context" is approximately the
same. It keeps a set of mapped attributes (or topologies in our case) in
scope for a specific hierarchy of events/objects that are being processed.
It may be possible to look at a "basic" Repast model to begin to see
this applications power:
Global Context
(1.SimModel)
|
Spatial Topology ---------> Localized Context
(2.Space, Graph...) (3. Agent)
|
Game Topology -----> Ultimate Decision
(4. a set of possible Decisions)
This sort of structure would allow one not only to "hot swap" various
Spatial and Graph Topologies at level 2, but to also "hot swap" various
Gaming strategies applied at the "scope" of each Agent. A Game then
becomes a topology of related "decisions" that an Agent may decide
between when being processed, different decision topologies would have
different content and structure thats independent of the actual
"Decisions".
I've been playing around with "Functors" on another project. Functors
are basically Objects that can perform a "function" on a set of objects.
If "Decisions" were "Functors" in a RePast model then they could
encapsulate a coded "action" that is to be performed on an Agent in a
Topology of that model. In a generic "Gaming" framework, the user would
only need to write "Decisions" that would be performed. The framework
could provide generic API's upon which these Decisions would be coded.
-Mark
|