MASON-INTEREST-L Archives

September 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:
Sat, 29 Sep 2012 13:37:47 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (18 lines)
Quad trees and related range trees work great, with a very big caveat: you can't change the data or their locations.  If you change anything you have to rebuild the tree, which is avery expensive operation indeed.  That means that quad trees make sense for data which is static and permanent.  MASON's lookup mechanisms are meant for data which is changing at any time without warning.  Also Quad trees will only make sense for sparse data.  Non-sparse grids will not benefit at all from them.

So with that caveat, building a quad tree would be a cute addition to SparseGrid2D and SparseGrid3D (and Continuous grids).

Sean

On Sep 29, 2012, at 9:57 AM, Eric 'Siggy' Scott wrote:

> Neighborhood lookups on Grids being too slow to be useful in most cases, is there any reason (besides that it takes work) that we can't replace the existing implementations to use a quad tree or related method?
> 
> Siggy
> 
> -- 
> Ph.D. Student in Computer Science
> Volgenau School of Engineering
> George Mason University
> 

ATOM RSS1 RSS2