On 3/18/2014 10:48 PM, S. Dale Morrey wrote:
It's a severely resource constrained environment. Think a j2me
feature phone as a possible target.
I get a data file from an external source periodically, but a DB is
not an option here, there just isn't enough room for the overhead and
that really seems like overkill for something like this.
I can't see the search being frequent enough to warrant more than a
few hours of tinkering, but I would like the search to be as snappy as
possible.
It can easily be "as the crow flies" so we don't need to be worried
about best path, just closest point.
Anyways thanks for the advice.
I wasn't suggesting a database, that's just silly. I also work in
resource constrained environments (sometimes as constrained as a PIC18),
but that doesn't mean I wouldn't setup an in-memory tree of some sort
(instead of the array/vector) if I needed to do a search a lot of
times. Even a linked list could be sorted in various ways. Anyway, if
it's an array/vector there's really no avoiding checking every single
item, because there's nothing saying the next item can't have a shorter
distance result. It's an easy calculation and all that, but it's still
going to be O(n) regardless of the approach.
-Tod Hansmann
/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
