On Thu, Apr 11, 2013 at 1:18 AM, Matt L. Miller <[log in to unmask]>wrote:

> MASON has always gone a long way out of the way to make sure that
> implementers don't
> accidentally do things that will compromise performance. ... But as we
> attempt to do more complicated things, we reach a fork:
> we can make things elegant and reasonably straightforward for the advanced
> coder but
> allow greenhorns to shoot themselves in the feet, or we can make things
> complex and
> difficult to implement, but ensure that no one is accidentally doing silly
> things. I think with
> GeoMASON we have reached that fork and, indeed, moved past it.
>

I agree that we've arrived at this conundrum.  However, I feel that MASON
has always been a little biased towards more seasoned practitioners since
some modicum of programming skills are required to use it.


> ...
> Now, I do understand that updates to the QuadTree are quite expensive, so
> we might not
> want to do them very often. In fact, I would perhaps suggest that one
> might want to lazily
> schedule that update to the spatial index only when one has made an actual
> change to the
> field contents.


Since presumably the practitioner would know the best way to implement such
an approach, I chose a design that would give that practitioner the
flexibility that they'd need.  Unfortunately doing so does break the
Principle of Least Astonishment in that the expectation of most users would
be that the field is always up to date regardless the set of additions and
removals and changed objects.  :(  I'm open to ideas on how to best resolve
this problem.

Meanwhile, I just committed a change, per Sean's suggestion, whereby a
dirty flag is set if an object within the field is moved via
setGeometryLocation() or is remove()'d.  Thus updateSpatialIndex()
invocations are NOPs if the dirty bit is not set so incurring minimal
runtime penalty, which means that users can freely invoke that in each time
step even if nothing has changed.  Unfortunately the user will still need
to manually set up such a regular invocation, though at least there's a
convenience function to make this a little easier,
scheduleSpatialIndexUpdater().

However, I have an alternative suggestion: the REAL problem, I think, is
> that we're having to
> put agents onto the GeoVector spaces instead of on more efficient, basic
> MASON grids or
> continuous fields, if we want them to align to the underlying GIS
> landscape. ...


GeomVectorFields are more than mere containers for geometries.  They also
provide associated semantics to support such questions as "What country is
this agent in?", "How many agents are currently in this county?", and
 "What are the adjacent voting precincts?"  These semantics are currently
absent in MASON 2D continuous spaces.