Complete.Org: Mailing Lists: Archives: freeciv-dev: January 2002:
[Freeciv-Dev] Re: [RFC] Tech costs and AI problem
Home

[Freeciv-Dev] Re: [RFC] Tech costs and AI problem

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Gregory Berkolaiko <gberkolaiko@xxxxxxxxxxx>
Cc: freeciv development list <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Re: [RFC] Tech costs and AI problem
From: Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>
Date: Thu, 10 Jan 2002 20:15:28 +0100
Reply-to: rf13@xxxxxxxxxxxxxxxxxxxxxx

On Thu, Jan 10, 2002 at 06:15:32PM +0000, Gregory Berkolaiko wrote:
>  --- Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx> wrote: 
> [...]
> >     k = pplayer->ai.num_unknown_techs[unit_types[i].tech_requirement];
> >     ...
> >     l = k * (k + pplayer->research.techs_researched) *
> > game.researchcost /
> >        (game.year > 0 ? 2 : 4); /* cost (shield equiv) of gaining these
> > techs */
> > 
> > K is the number of techs which have to researched till the goal tech
> > (unit_types[i].tech_requirement) _can_ be researched/is reachable.
> > 
> > Note that currently
> > 
> > int total_bulbs_required(struct player *pplayer)
> > {
> >   int timemod = (game.year > 0) ? 2 : 1;
> > 
> >   return timemod * pplayer->research.techs_researched *
> > game.researchcost;
> > }
> > 
> > So I assume that the condition in the AI code can wants to mimic this.
> > 
> > I want to compute l from a call to total_bulbs_required_for_goal
> > (which is the new method for this).
> > 
> > If we assume that
> >   s=pplayer->research.techs_researched,
> >   rc=game.researchcost and 
> >   tbrfg=the result from the total_bulbs_required_for_goal 
> > than the old method will compute:
> > 
> >  l_old = (k*k + k*s) * rc
> 
> you mean l_old = (k*k + k*s) * rc / 4 ?
> factors of 2 are my weak point :(

Yes.

> > the new method calculates correctly:
> >  tbrfg = (0.5*k*k + (s - 0.5)*k) * rc
> > 
> > So for large k's a good approximation would be "l_new = tbrfg / 2" but
> > this
> > fails for small ks:
> >  l_old(k=1) = (s + 1)*rc
> >  l_new(k=1) = (s*rc)/2
> > 
> >  l_old(k=2) = (2*s + 4)*rc
> >  l_new(k=2) = ((s + 1)*rc)/2
> > 
> > I would have no problems if these numbers wouldn't get mixed with
> > build_costs and the number of cities.
> > 
> > So any advise from the "AI-people"?
> 
> Prediction: Ross will say "don't worry too much about it, it's just some
> fuzzy weighting".  And he will be right :)

I'm also expecting this.

> I agree with you that the right formula is
>   tbrfg = (0.5*k*k + (s - 0.5)*k) * rc
> althoug I prefer the traditional way
>   tbrfg = (s*k + k*(k-1)/2) * rc  
> both because it's traditional and because it's obvious that the result is
> integer.

But not this easy to compare.

> I expect variable "l" to be useful only when s is big and when k is small
> (because the tech tree is comparatevely wide and because AI shouldn't
> pretend it is standing on the shoulders of giants).  So if you want to
> keep your approximation as close as possible to the wrong one, aim to get
> the s prefactor right (sort out the factors of 2 too).

> BTW, in "AI-people", are quotation marks expressing sarcasm? ;)

No. The first version didn't had these quotation marks. Don't ask me
why the final version had them.

> P.S. I reread my email and found that it's full of pretentious rubbish. 
> The message in clear English is "useful ranges are: k is of order 1 (1, 2
> or 3), s is of order 10 (20, 30 or more)"

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
  +#if defined(__alpha__) && defined(CONFIG_PCI)
  +       /*
  +        * The meaning of life, the universe, and everything. Plus
  +        * this makes the year come out right.
  +        */
  +       year -= 42;
  +#endif
    -- Patch for 1.3.2 (kernel/time.c) from Marcus Meissner


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