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 <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Re: PATCH: rand_pos function and usage(PR#1017)
From: Jason Dorje Short <vze2zq63@xxxxxxxxxxx>
Date: Wed, 24 Oct 2001 01:19:00 -0400
Reply-to: jdorje@xxxxxxxxxxxx

"Ross W. Wetmore" wrote:

<snip context: RAND_POS_CHECKED macro>

> This clearly significantly increases the computation effort,

Not necessarily.  In a mostly-grassland map the overhead isn't necessary,
but in a highly-forested or highly-desert map the fact that the loops are
bounded would be a big advantage.

> introduces
> a lot of almost impossible to solve issues relating to the size of the
> allocated arrays vs the selection space and final selection sixe,

It uses a fair amount of memory.  This memory is freed shortly afterwards,
and shouldn't be a problem overall.

> and
> clearly changes the distribution function.

Yes; the old method approximated a binomial distribution for the quantity of
most of these terrain types.  It would be pretty easy to recreate such a
distribution by picking the numbers for each terrain more intelligently
(which is why several of them have "FIXME" comments by them in my patches).

> The interface is also so incredibly unwieldy and limiting that you
> really can't do any significant filter operations.

It is certainly ugly.  If we follow Raimar's idea of having actions within
the loop, it will be even more ugly (although more powerful).

> I'm not sure why anyone would waste time trying such things :-).
> 
> There are better and higher priority things to do to fix freeciv.

Unfortunately, some of them depend on this.  I would like to make mapgen.c
topology-independent.  This is fairly easy to do (I've already provided a
full patch to do it), but until we agree on how to do it we'll still be
stuck here and no new topologies will be possible.

Note that I'm not asking that mapgen provide good maps for every topology. 
I require only two things: that the map generation not be any worse for the
current topology, and that it is able to make a map (any map) for an
arbitrary topology.  I do not particularly care about speed or memory usage,
since such things shouldn't be a problem during map generation anyway.

Your corecleanup patch doesn't touch on mapgen.c so I have no other work to
go by here.  How would you change mapgen to accomplish the above two goals? 
Any solution is OK with me.

jason


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