Complete.Org: Mailing Lists: Archives: freeciv-dev: April 2005:
[Freeciv-Dev] Re: (PR#12833) consider_settler_action simplification (rev
Home

[Freeciv-Dev] Re: (PR#12833) consider_settler_action simplification (rev

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
Subject: [Freeciv-Dev] Re: (PR#12833) consider_settler_action simplification (rev.)
From: "Brian Dunstan" <bdunstan149@xxxxxxxxx>
Date: Tue, 19 Apr 2005 15:44:38 -0700
Reply-to: bugs@xxxxxxxxxxx

<URL: http://bugs.freeciv.org/Ticket/Display.html?id=12833 >


--- Peter Schaefer <peter.schaefer@xxxxxxxxx> wrote:
> 
> <URL:
> http://bugs.freeciv.org/Ticket/Display.html?id=12833
> >
> 
> Well I trust you will tell me when I get on your
> nerves:
> 
>  I looked at the source and it seems to me it 
> 1)iterates over all cities, all tiles, and there is
> no break or return
> to return early
> 2)higher value of newtiles is good
> If I go wrong in the above, I'm probably wrong in my
> ideas below.
> 
> Now, thinking aloud, if one had cache of     
> >int diff = new_tile_value - old_tile_value; 
> such that one could determine max over all tiles/all
> tiles within my
> borders on this continent of(diff), or if one would

I think this is a good idea. 
(new_tile_value-old_tile_value) does not depend on the
unit performing the activity, so it could be stored
with the city.  I think with that, and adding an
iterator over all the activities, we could get away
drastically reducing the size of
evaluate_improvements(), and doing away with
consider_settler_action() completely.

With a simpler setup, it might be easier to implement
a solution for the pollution cleanup problems, etc.

evaluate_improvements() (oversimplified) could look
like this:


evaluate_improvements(punit, best_act, best_tile) {

 city_list_iterate(pplayer, pcity) {
  city_map_iterate(pcity, ptile) {
  
    unit_activity_iterate(punit, activity) {
      if(we_can_do_this_activity()) {
     
        time = mv_turns + get_turns_for_activity()

        total_value = 





}







> 
> then one should be able to break off the loop early,
> assuming the loop
> would be rewritten to proceed from tiles close to
> the settler to tiles
> far away, when the movement cost gets to high to
> justify the possible
> max benefit of (max-bestdiff), similar to using
> alpha-beta pruning in
> chess. This would largely supercede the need for
> >&& WARMAP_COST(ptile) <= THRESHOLD * mv_rate
> and make it redundant except as a failsafe.
> 
> I realize I am assuming
> 1) that is somehow possible to loop over all
> destinations close to a settler
> 2) (optionally) that the improvement diff for each
> tile can and is
> predetermined(which may be good anyway), requiring a
> reverse lookup of
> all cities that may use the tile.
> 
> I hope I made sense,
>  bless papa razzi,
>   yours,
>     Peter
> 
> On 4/19/05, Brian Dunstan <bdunstan149@xxxxxxxxx>
> wrote:
> > 
> > <URL:
> http://bugs.freeciv.org/Ticket/Display.html?id=12833
> >
> > 
> > --- Mike Kaufman <kaufman@xxxxxxxxxxxxxxxxxxxxxx>
> > wrote:
> > >
> > > <URL:
> > >
> http://bugs.freeciv.org/Ticket/Display.html?id=12833
> > > >
> > >
> > > On Tue, Apr 19, 2005 at 07:47:35AM -0700, Brian
> > > Dunstan wrote:
> > > >
> > > > Against dropping the divisor, or against
> > > converting to
> > > > floating point?
> > >
> > > against converting to floating point.
> > >
> > > -mike
> > 
> > Yeah I don't think a decision  on that is
> imminent.
> > It would be a lot of work to do, and as you say
> there
> > are arguments pro and con with respect to speed,
> > accuracy, etc.
> > 
> > 
> > __________________________________
> > Do you Yahoo!?
> > Plan great trips with Yahoo! Travel: Now over
> 17,000 guides!
> > http://travel.yahoo.com/p-travelguide
> > 
> >
> 
> 
> 


                
__________________________________ 
Yahoo! Mail Mobile 
Take Yahoo! Mail with you! Check email on your mobile phone. 
http://mobile.yahoo.com/learn/mail 





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