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.