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

["Jason Short" <jdorje@xxxxxxxxxxxxxxxxxxxxx>]

<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).

-jason