Complete.Org: Mailing Lists: Archives: freeciv-dev: December 2001:
[Freeciv-Dev] Re: freeciv2 kernel,modules and rulesets
Home

[Freeciv-Dev] Re: freeciv2 kernel,modules and rulesets

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Andrew Sutton <ansutton@xxxxxxx>
Cc: Julian Rüth <julian.rueth@xxxxxx>, Petr Baudis <pasky@xxxxxxxxxxx>, freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: freeciv2 kernel,modules and rulesets
From: Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>
Date: Mon, 3 Dec 2001 15:44:50 +0100
Reply-to: rf13@xxxxxxxxxxxxxxxxxxxxxx

On Mon, Dec 03, 2001 at 09:13:51AM -0500, Andrew Sutton wrote:
> > On Mon, Dec 03, 2001 at 08:34:24AM -0500, Andrew Sutton wrote:
> > > closer... i was thinking of a map that stored some informatic structure
> > > about the tile. it could be keyed on the x,y coordinate of the tile. if
> > > nothing's on the tile, there's no associated key in the map. it's a
> > > constant time lookup and hashtables _are_ built for sparsely populated
> > > arrays :)
> >
> On Monday 03 December 2001 09:11 am, Raimar Falke wrote:
> > And with 4 extra bytes we need only one (exactly one) memory access
> > (which is quite constant to me).
> 
> both are equally good ideas. one is an optimization on size, the other time. 
> actually, in the long run, it's probably going to be more effective to use 
> the per-tile implementation because of the crappy insert time on hash tables 
> (if i remember my CS right). and you're right, the extra bytes aren't overly 
> significant unless you start talking about enormous maps (1024x1024?) god 
> would that be fun.
> 
> maybe a good solution would be to implement both and heuristically choose the 
> algorithm based on maps size...

Only one comment: the code has to be audited/changed for use of maps
larger than 255x255.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 1 + 1 = 3, for large values of 1


[Prev in Thread] Current Thread [Next in Thread]