Complete.Org: Mailing Lists: Archives: freeciv-dev: October 2001:
[Freeciv-Dev] Re: PATCH: rand_pos function and usage (PR#1017)
Home

[Freeciv-Dev] Re: PATCH: rand_pos function and usage (PR#1017)

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: freeciv-dev@xxxxxxxxxxx
Cc: bugs@xxxxxxxxxxxxxxxxxxx
Subject: [Freeciv-Dev] Re: PATCH: rand_pos function and usage (PR#1017)
From: jdorje@xxxxxxxxxxxxxxxxxxxxx
Date: Thu, 18 Oct 2001 11:13:48 -0700 (PDT)

Raimar Falke wrote:
> 
> On Wed, Oct 17, 2001 at 10:01:24PM -0700, jdorje@xxxxxxxxxxxxxxxxxxxxx wrote:
> > The attached patch creates a function, rand_pos(&x, &y) that determines
> > a random map position.  It also uses it in place of all similar code.

> > This could have efficiency problems if we were looking for a very small
> > subset of positions on the map.  Fortunately, there is no such code
> > right now.
> 
> I'm also converned about efficiency problems. Can't rand_pos take the
> range of allowed distances from north. Which now are from
> 0..map.ysize-1 and latter come from 0..height-1.

This doesn't sound so good.  Outside of map generation stuff (which
shouldn't be a concern), the only check that's done on the returned
value is to make sure it's not on one of the poles.  In other words,
this will attain virtually no speedup except during map generation.

This method also isn't really very general.  For instance, how does it
apply to a torus map?  A torus map would probably have no polar regions
(everything would be tropical); this would be easy to achieve using the
checks I'm proposing but difficult or impossible if you build that
information into the rand_pos function.

Finnaly, this would make the code much uglier (IMO) and would make
rand_pos a topology-dependent function, which I'd like to avoid.


What we can do is use is_normal_map_pos2 in the rand_pos function to
attain a decent speedup for the current map.

jason



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