Complete.Org: Mailing Lists: Archives: freeciv-ai: April 2002:
[freeciv-ai] Re: Approximate win_chance

[freeciv-ai] Re: Approximate win_chance

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: rf13@xxxxxxxxxxxxxxxxxxxxxx
Cc: "Ross W. Wetmore" <rwetmore@xxxxxxxxxxxx>, Gregory Berkolaiko <Gregory.Berkolaiko@xxxxxxxxxxxx>, freeciv-ai@xxxxxxxxxxx
Subject: [freeciv-ai] Re: Approximate win_chance
From: Raahul Kumar <raahul_da_man@xxxxxxxxx>
Date: Wed, 24 Apr 2002 06:52:07 -0700 (PDT)

--- Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
> AFAIK the current win_chance isn't an approximation but returns the
> exact value. Or do I'm mistaken about that?

Correct, but you're barking up the wrong tree. Quoting Greg from earlier email

>I ran some simulations with my approximate win_chance formula.
>It doesn't perform as well as I initially thought, but it's definitely 
>better than the current system we have in most AI routines.
>Current system:
> A_rating = A_strength * A_HP * A_FP;
> D_rating = D_strength * D_HP * D_FP;
> chance = A_rating^2 / ( A_rating^2 + D_rating^2 )
> My formula:

This formula can be found for example in functions like the one below:

 base_assess_defense_unit(struct city *pcity, struct unit *punit,
 51 bool igwall, bool square, int wall_value)
 52 {
 53 int v;
 54 55 if (!is_military_unit(punit)) {
 56 return 0;
 57 }
 58 v = get_defense_power(punit) * punit->hp *
 59 (is_sailing_unit(punit) ? 1 : unit_type(punit)->firepower); <-- Here is the
offending lines, 58-59

Which can be replaced with Greg's approx_win_chance rather nicely. Net gain.
I'm not suggesting that Greg's function be the only one used as you seem to be
suggesting. I thought the idea was that the exact win_chance and
approx_win_chance would co-exist.

The exact win_chance is far too slow to be used everywhere. Greg is correct in
saying the performance hit is too big.

Greg, clarify this. Do you want to replace win_chance completely? If so,
Raimar's right and the errors are unacceptable. If on the other hand, if you're
doing what I think you're doing, and just want to replace those crappy
approximations in  for e.g base_assess_defense_unit, I fully support this aim.

> As I said this would be the ideal solution. If the current win_chance
> returns the correct value we have to have an estimation of the error
> which a new win_chance will produce.
> > A formal mathematical proof is over the top. No
> > doubt Greg can do it, but I feel this is asking too much of contributors.
> The whole possible set is very large, I'm not aware of any range limits to
> or firepower, although attack power seems to be limited to <= 99.
> > 
> > In fact, can I ask you for a formal proof of combat.c? There are a number
> of areas in that region of code that concern me:
> > No apparent range limits to defence power, and attack power seems to be
> limited only to 99. 
> Where?

If you're asking about the attack power limit, there are no bonuses to attack
power, and 99 is the special no for nukes. Which is why I believe there is a
limit on attack power.

There is NO bounds checking of any variable that I can spot anywhere.
Presumably this happens behind the scenes, when rulesets are loaded, but I
can't find it. It makes me worried. This smells like an overflow waiting to
happen. What happens if someone uses the max values for 

defence <-- This is the real worry. There is no apparent limit to how high
defence can get. There should be a check for this.

Don't forget that these numbers are then squared. Int may not be big enough. 

You need look no further than base_assess_defense_unit, to see a function where
there is a overflow waiting to happen. There are lots of others in AI
in case you are wondering. This is not an isolated problem.


It's vital to remember who you really are. It's very important. It isn't a good
idea to rely on other people to do it for you, you see. They always get it
{Sourcery, 1988, Terry Pratchett}

Do You Yahoo!?
Yahoo! Games - play chess, backgammon, pool and more

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