Menu
▾
▴
Re: [Repast-developer] Topology Notes
|
From: Laszlo G. <gu...@la...> - 2002-11-22 04:53:21
|
<html> Hi Guys,<br><br> I'm sorry for taking so long reacting, but there's so many things<br> going on right now. (Not excluding selling the furniture and the=20 car<br> in preparation to moving back to Europe.) So, my schedule was and<br> is a bit hectic. Fortunately, though, both Anita (my wife) and I have <br> saved up some days off, so we're gonna take off for a last vacation=20 <br> soon. Hopefully, I get back for the last couple of days much more <br> relaxed/productive...<br><br> However, I wanted to get back to you on this before that happens.<br> I think, Mike has summarized our discussion rather well. The only<br> thing remained to say is about displaying these things. In principle,<br> the Drawable interface works well: it basically maps an agent into<br> a 2D coordinate system, plus provides a way for it to draw itself.<br> This should be general enough.<br><br> Except that it kind of makes it hard for an agent to participate in<br> several [switchable] 'spaces' or to display itself on different displays <br> of the same [possibly N-dimensional] space. Now, I don't necessarily <br> think that it is time now [just before 2.0] to blow up the whole gui package.<br> However, I've been doing some experimentation and created my<br> own ContextMapping (well, I call them contexts, but they are, kind<br> of, generalized topologies) interface whose methods take an agent and<br> - map it into an (X,Y) /screen/ coordinate,<br> - return its Dimension,<br> - draw it on the screen.<br><br> I just thought I'd share this with you. (See the attachment.) <br> Please, do not look at its performance yet! On the other hand,<br> it's kind of complex, so I won't blame you not want to start<br> with it right now.<br><br> - - - - - <br><br> OK. In this model, I've taken the 'space/topology' issue a step <br> further. (?) [Don't think I'm suggesting you should start implementing <br> any of this. Rather, I just want to share my crazy visions with you.]<br><br> Now I think that the bottom line of all these 'space/topology'<br> issues is the concept of a Relation. It is really nothing else, but an Edge <br> on a network, so one nice thing about this approach is that it provides <br> a natural way to unify the 'grid-based' and the network models.<br><br> OK, so I call them relations, not Edges, what's the difference?<br> Technically, my implementation is nothing more than providing<br> ways to sort out edges according to their types. This way, I have<br> general methods to say, "Give me the related nodes according to <br> relation R", R being a parameter.<br><br> My 'contexts' create and update the relations and all the Model/Agent <br> do is to query and use them, via these general methods. This way, by <br> replacing the context, you can place the agents into vastly different <br> environments, as long as they all define the same relations.<br><br> From this point of view, the topologies/spaces just define special, perhaps<br> parametrized [with distance] 'neighborhood' or 'close-to' relations. Storing<br> the agents on a grid internally is just an efficient way of implementing this.<br> (Naturally, it is debatable whether the relations/edges define special kinds<br> of topologies, or the other way around, but this time, I just went with the<br> latter option.)<br><br> Well, let me know what do you think. Note, however, that I'll be out of<br> town till December 3. So, don't get mad at me if I won't answer=20 them<br> immediately. (Well, that's kind of usual from me, sadly=20 enough.)<br><br> Take care!<br><br> Gulya<br><br> PS: I can't resist to put this in here: as a long shot off the 'relation burble':<br> this could, in fact, finally lead to the 'DB-based' simulation I've been<br> 'visioning' for a while. I mean, if relations are a central concept in the<br> architecture, and the model's and the agents' logic is formulated according<br> to this, it could be possible to actually implement them by storing them<br> in a relational DB. Then, in principle, one could do cool stuff, like <br> defining 'dynamic relationships' via joints, or creating triggers, etc.<br> I'm not sure if it's necessarily more efficient, but wouldn't it be cool?! ;-) <br> [Enough of me now! :-)]<br><br> At 07:15 PM 11/15/2002 -0600, North, Michael wrote:<br><br> <blockquote type=3Dcite class=3Dcite cite><font face=3D"Times New Roman,= Times">Tom:<br> </font><br> <font face=3D"Times New Roman, Times"> <br> </font><br> <font face=3D"Times New Roman, Times">The topology issues that we discussed might be represented as follows:<br> </font><br> <font face=3D"Times New Roman, Times"> <br> </font><br> <font face=3D"Times New Roman, Times">1.)</font><font face=3D"Times New= Roman, Times" size=3D1> </font>An abstract Topology class or interface can be defined:<br><br> <font face=3D"Times New Roman, Times">a.</font><font face=3D"Times New= Roman, Times" size=3D1> </font>The class has a method, getDistance(Object o1, Object o2), that returns the distance between any two objects.<br><br> <font face=3D"Times New Roman, Times">b.</font><font face=3D"Times New= Roman, Times" size=3D1> </font>The Topology class has appropriate methods to get neighbors within a certain range such as getNeighbors(Object o1, double range) .<br><br> <font face=3D"Times New Roman, Times">2.)</font><font face=3D"Times New= Roman, Times" size=3D1> </font>Three or more concrete Topology implementation classes can then be defined:<br><br> <font face=3D"Times New Roman, Times">a.</font><font face=3D"Times New= Roman, Times" size=3D1> </font>An implementation for Moore neighborhoods, von Neumann neighborhoods, and hexagonal neighborhoods based on the current grid implementation can be defined. This would use the current array-based grid storage and maintain backward compatibility. Since it is essentially the current implementation, it would run as fast as the current code.<br><br> <font face=3D"Times New Roman, Times">b.</font><font face=3D"Times New= Roman, Times" size=3D1> </font>An implementation for metric spaces can be defined that uses trees to store objects and find neighbors. This can be done since the rules of a metric space allow tree storage. For example see <a href=3D"http://www.vldb.org/conf/1997/P426.PDF">http://www.vldb.org/conf/= 1997/P426.PDF</a>. Other implementations are also available, especially for large lists. For example, see <a href=3D"http://portal.acm.org/citation.cfm?id=3D328959&dl=3DACM&c= oll=3Dportal">http://portal.acm.org/citation.cfm?id=3D328959&dl=3DACM&am= p;coll=3Dportal</a>. This implementation would run slower than the current code but it would still be reasonable for most problems. The price of slower execution is made up for by the added flexibility.<br><br> <font face=3D"Times New Roman, Times">c.</font><font face=3D"Times New= Roman, Times" size=3D1> </font>An implementation for completely abstract (i.e. non-metric) spaces can be defined that uses a simple list to store objects and a na=EFve all pairs matching algorithm to find neighbors. The algorithm will simply test the distance between each object to find neighbors. This implementation will be much slower than the current code for large lists but the slower execution will be made up for by the increased flexibility, at least for initial testing. Users that find they need a particularly abstract notion of space are free to develop optimized versions of the Topology class as they see fit.<br><br> <font face=3D"Times New Roman, Times">3.)</font><font face=3D"Times New= Roman, Times" size=3D1> </font>Users select the fastest concrete implementation class that supports their model's notion of space. Of course, users are also free to extend or add to the existing concrete classes.<br><br> <font face=3D"Times New Roman, Times"> <br> </font><br> <font face=3D"Times New Roman, Times">Mike<br> </font><br> <font face=3D"Times New Roman, Times"> <br> </font><br> <font face=3D"Times New Roman, Times"> </font></blockquote></html> |
