MASON-INTEREST-L Archives

August 2012

MASON-INTEREST-L@LISTSERV.GMU.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Sean Luke <[log in to unmask]>
Reply To:
MASON Multiagent Simulation Toolkit <[log in to unmask]>
Date:
Thu, 16 Aug 2012 07:28:56 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (33 lines)
Thanks for your comments, Stuart, they were very insightful.

On Aug 16, 2012, at 5:46 AM, Stuart Rossiter wrote:

> Maybe I'm being simplistic (haven't been following the discussion *that*
> closely), but why not just code the neighbours-related methods so that, either:
> a) they return an exception if a distance > width is specified
> b) just have initial if clauses that return all objects if a distance >=
> min(width, height) is specified

The issue is that not all space is bounded or toroidal: it can be unbounded, in which case neither of the above is valid.  In the case of (a), this means that we had a method whose bounds varied based on the mode it was in.  In the case of (b) this only works if the mode is bounded or toroidal, and the neighborhood is rectangular.  Otherwise it fails.

> Given that one of the most common idioms will be 'get my neighbours', then
> sparse grids could still be confusing in that the includeOrigin parameter
> will exclude other agents at the origin when this perhaps was not expected.

Tbis is very true.  Of course, the includeOrigin parameter is largely useful when you're gathering slots which can only have one item in them (DoubleGrid2D, IntGrid2D, ObjectGrid2D).

MASON has additional neighborhood functions for retrieving objects in locations rather than locations proper.  Perhaps these functions should not have that option?

> One possible solution would be to have companion methods such as:
> 
> For sparse grids (or any future grids where co-located objects are possible):
> 
> getNeighborsMaxDistanceOfTarget(Object target, boolean includeOrigin, int
> dist, boolean toroidal, IntBag result, IntBag xPos, IntBag yPos)

True but what about DenseGrids, which have a similar situation, but where the object can be located multiply?

It seems to me that the right thing here would be to eliminate the includeOrigin option for looking up objects rather than locations, and if the user wants to delete an object, he can just remove it from the results bag.

Sean

ATOM RSS1 RSS2