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

["Brian Dunstan" <bdunstan149@xxxxxxxxx>]

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


--- Jason Short <jdorje@xxxxxxxxxxxxxxxxxxxxx> wrote:
> 
> <URL:
> http://bugs.freeciv.org/Ticket/Display.html?id=12833
> >
> 
> Brian Dunstan wrote:
> 
> > Right.  I think that 4x factor can be dropped.  If
> > there is a preference for tiles already worked,
> then
> > there will be many tiles that are not useful
> before
> > improvement, but very useful after.  So the city
> will
> > not work these tiles until they are improved, but
> the
> > worker will not improve them until they are worked
> (or
> > at least, it may end up trekking to the other side
> of
> > the map to do something else before making the
> > improvement)
> 
> I don't think the 4x factor should be dropped, but
> should be changed to
> something a little more scientific.
> 
> For instance it's often beneficial to travel a short
> distance to build
> an irrigation on grassland that's in use by a
> different city, rather
> than to build irrigation on a grassland we're
> standing on that isn't in
> use.  While it's true that one grassland is as good
> as another if
> they're both in range by the city (so the grassland
> we're standing on is
> just as good as the one next to us, if our city
> could use both but just
> happens to use the other one) I don't think there's
> a good way to
> account for this.
> 
> However 4x is a big difference.  I think it would be
> safe to assume that
> a tile we improve would be used by our city as soon
> as it grows.  That
> way we calculate the time it takes the city to grow
> (capped at 20 turns,
> maybe) and do a MAX of that with the time it takes
> to build the improvement.
> 
> Remember our ammortization needs to be done in two
> steps, and the
> current code only does the second step.
> 
> 1.  We need to calculate the value of the bonus K in
> perpetuity.  With a
> interest rate of 1/N (5%) this gives a perpetual
> value (P) of N * K.
> 
> 2.  We need to calculate how long it will be until
> we complete the work,
> and ammortize based on that.  This is also a simple
> calculation that can
> be done after the above one.  Thus the final value
> is V = P / (1 +
> 1/N)^T.  I believe this is what ammortize does (and
> I don't see why this
> is a problem since this is just an O(log T)
> operation).
> 
> Example 1: we have a tile that's in use.  Irrigating
> it gives +1 food,
> and will take 10 turns.  Interest rate is 5%.
> 
>   N = 20
>   T = 10
>   K = (+1 food) * (FOOD_WEIGHTING = 19) => 19
>   P = N * K => 380
>   V = P / (1 + 1/N)^T = 380 / (1.05 ^ 10) => 233
>   so the value is 233
> 
> Example 2: we have a tile that's in use. 
> Tranforming it gives +1 food
> and +1 trade and will take 20 turns.  Interest rate
> is 5%.
> 
>   N = 20
>   T = 20
>   K = (+1 food) * (19) + (+1 trade) *
> (TRADE_WEIGHTING = 12) => 31
>   P = N * K = 620
>   V = 620 / 1.05^20 = 234
> 
> Example 3: we have a tile that not in use. 
> Transforming it gives +1
> food and will take 5 turns.  But the city will grow
> in 10 turns.  This
> breaks down to be identical to example 1 since the
> time until use comes
> out to 20 turns.
> 
> Through crazy coincidence the numbers are almost
> identical.  But with
> floating-point comparison the example 2 is slightly
> larger, so this is
> the tile we should improve first.  Note that with a
> higher interest rate
> example 1 would become more profitable.
> 
> Finally note that in all of these the
> value-in-perpetuity is simply a
> constant factor of 20.  Unless the interest rate
> changes, and as long as
> we're doing comparisons only of
> things-that-exist-in-perpetuity, we can
> ignore it.  The only thing I can think of that a
> worker unit would do
> that isn't useful in perpetuity is building a
> fortress.  But maybe some
> of the "extra factors" that are added on aren't
> counted in perpetuity
> (though I think they are).  All this means that we
> can basically just
> ignore the calculation of P and go straight on to V.
>  Which is what the
> code does now (IIRC).

Yes, that's what the code should do.  This is the
central part of the settler-action amortization here:

  if (consider) {
    int diff = new_tile_value - old_tile_value;

    base_value = 
      diff * (in_use ? 64 : 16) + extra * 64;

    base_value = MAX(0, base_value);

    discount_value = amortize(base_value, delay);

    total_value = 
      ((discount_value * base_value)
        / (MAX(1, base_value - discount_value))) / 64;

  } else {
    total_value = 0;
  }


I think this would suffice:

if (consider) {
    int diff = new_tile_value - old_tile_value;

    base_value = 
MAX(0, new_tile_value - old_tile_value)
      diff * (in_use ? 64 : 16) + extra * 64;

    base_value = MAX(0, base_value);

    discount_value = amortize(base_value, delay);

    total_value = 
      ((discount_value * base_value)
        / (MAX(1, base_value - discount_value))) / 64;

  } else {
    total_value = 0;
  }





                
__________________________________ 
Do you Yahoo!? 
Plan great trips with Yahoo! Travel: Now over 17,000 guides!
http://travel.yahoo.com/p-travelguide