Complete.Org: Mailing Lists: Archives: freeciv-dev: March 2002:
[Freeciv-Dev] Re: [RFC] Caching AI values
Home

[Freeciv-Dev] Re: [RFC] Caching AI values

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: rf13@xxxxxxxxxxxxxxxxxxxxxx
Cc: freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: [RFC] Caching AI values
From: Gregory Berkolaiko <Gregory.Berkolaiko@xxxxxxxxxxxx>
Date: Thu, 21 Mar 2002 16:31:43 +0000 (GMT)

On Thu, 21 Mar 2002, Raimar Falke wrote:

> On Wed, Mar 20, 2002 at 07:16:37PM +0000, Gregory Berkolaiko wrote:
> > 
> > If a unit is killed, we call a function which does not recalculate 
> > anything by itself, but instead increments some "time" variable to show 
> > that the cached values have expired.  Then, the next time we try to access 
> > cached values, we will have to recalculate them.  This way we do not 
> > recalculate anything that isn't going to be used and avoid all these 
> > complex decisions "what to update" as well.
> > 
> > Of course each type of cached values will have it's own "time" variable 
> > associated with it.
> 
> This is known as lazy evaluation. You don't need a time field. A
> simple bit "valid" is sufficient.

My life seems to be full of discoveries which are already known and even 
have a name.

Anyway, simple bit won't do for me.  This is the sequence of event which 
is possible and can't be handled nicely by one bit:

* time = 1
1. Compute quantity x for city A (stamped: 1)
2. Compute quantify x for city B (stamped: 1)
3. Something happens which (might) render cached values of x in A and B 
   invalid.  Increment time.
* time = 2
4. Compute quantity x for city B (previous stamped 1 < time => should be 
   recalculated)

Now we have cached value in A, which isn't valid and a valid cached value 
in B.  We cannot describe this situation using only
bool x_cache_valid;


G.




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