[freeciv-ai] Re: Amortize

[Gregory Berkolaiko <Gregory.Berkolaiko@xxxxxxxxxxxx>]

Just a random collection of comments:

1. I would call d(t) "inflation".
2. Your ideas are very interesting but are also very complicated.  Unless 
we are trying to win the Nobel Prize in Economics, I think we should stick 
with the current system -- for simplicity.
3. As you both pointed out, there are 3 classes of surplus:
- constant (step function)
- one-time bonus (delta function)
- variable (step multiplied by some function)

The handling of first two is simple, just multiply by d(t) and integrate 
--- and you don't even have to integrate, since integral of exponential is 
exponential.

The handling of the third in any scientific way is impossible as the 
underlying function is unknown.

So the third case should be dealt with on an individual basis.  In
particular it's city-buiding, where there are two distinct phases:  
building the first few cities (as soon as possible) and building further
cities (in the best locations).  Now we need a nice estimator to evaluate
each spot as a function of the local terrain and then, for simplicity,
multiply it by some decay function.  I would suggest multiplying it by
something like
        ( (C+1)/(C+2) )^delay
where C is the number of cities we currently have.

G.

On Wed, 22 May 2002, Raimar Falke wrote:

> On Wed, May 22, 2002 at 08:46:24PM +0200, Per I. Mathisen wrote:
> > On Wed, 22 May 2002, Raimar Falke wrote:
> > >  - delay: number of turns that you have to wait till the action will
> > >  produce something.
> > >  - surplus(turn) or (s(t) for short):
> > >     - t>=0
> > >     - t is relative shifted by current_turn+delay. So s(0) is really
> > >     s(current_turn+delay).
> > >     - may be < 0
> > >  - constant surplus: s(t)=const for all t (simple terrain improvements
> > >  have a constant surplus)
> > >  - non-constant surplus: example is the founding of a new city. The
> > >  surplus depends on the city size and this size isn't fixed.
> > >  - discrete surplus: s(t) is only defined for integer values of t
> > >  - decay function: d(t)
> > >    - d(0)=1
> > >    - d(t)=0 if t->inf
> > >    - d(t) is monotonic
> > >    - example d(t)=0.5^t
> > >
> > > Problem 1: we want to decide weither an action A1 which has a delay of
> > > delay_a1 and a surplus_a1 should be taken or action A2.
> > >
> > > First solution: draw up the s(t) and calculate the area under the
> > > curve.
> > >
> > > Problem 1': the area is in most cases infinite.
> 
> > No, only until endyear and/or spacerace arrival. Games with higher (end
> > year - current year) have smaller area (if I understood your definition
> > correctly), and the area shrinks for every turn.
> 
> Yes. But the model I have used is a bit more abstract. Also an endyear
> of 5000 is quite a bit.
> 
> > > Problem 2: we want to punish long delays.
> > >
> > > Solution 2.1: we multiply the surplus with a decay function. So larger
> > > delay give smaller overall surplus.
> > >
> > > Solution 2.2: _if_ we had finite areas we don't need to care about the
> > > delay since it will just reduce the area.
> 
> > Ah, but some improvements (notably cities) give you exponential growth,
> > and you cannot know the exponential rate, because that is largely decided
> > by the decisions of the enemy.
> > 
> > I think a decay function is necessary, but the decay rate should be
> > decided by our evaluation the possibilities for exponential growth, which
> > in turn largely hinges on our evaluation of the enemy (and endyear and
> > spacerace).
> 
> Ack if we at some point multiply decay and non-constant surplus. Than
> the currently used decay function may be too weak to bring the product
> to zero.
> 
> > > Solution 2.1 is the one used in current code. As d(t) (23/24)^t is
> > > used. This means a decay rate of 1/24 ~= 4.16%. So this decay function
> > > has a halflife of ln(2)/(1/24)=ln(2)*24 ~= 16.635 turns.
> > 
> > Interesting.
> > 
> > > Note that the current code can only handle constant surplus. If there
> > > is a non-constant surplus you can either use a symbolic integration
> > > (hard to very hard) or a numberic integration (also not easy, note
> > > that the time horizon is unlimited).
> > 
> > We might want to introduce the AI to barriers. Let's say we want to invade
> > a given enemy in 20 turns. Then we try to get stuff ready in that time
> > horizon, because we want our military units to be ready, and our
> > evaluations and needs will probably be turned upside down then anyway,
> > leading to discarding previous build evaluations and targets that are not
> > finished.
> > 
> > This is particularily useful when we have AI diplomacy. Then we can use
> > periods of peace to expand, and stop building new cities and peaceful
> > buildings in time for war (when we will probably have to crashbuy lots of
> > military hardware anyway).
> 
> Although I have no hard fact I think that this isn't a good
> solution. If you have certain discrete modes you switch between then
> this can be exploited by human users. Also a certain global mode makes
> you too weak. You always want to produce some units (and if it only
> with 1% of your total production).
> 
>       Raimar
> 
>