Complete.Org: Mailing Lists: Archives: freeciv-dev: April 2002:
[Freeciv-Dev] Re: server/settlers.c cleanup 3
Home

[Freeciv-Dev] Re: server/settlers.c cleanup 3

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Gregory Berkolaiko <Gregory.Berkolaiko@xxxxxxxxxxxx>
Cc: Markus Linnala <maage@xxxxxxxxx>, freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: server/settlers.c cleanup 3
From: "Ross W. Wetmore" <rwetmore@xxxxxxxxxxxx>
Date: Tue, 16 Apr 2002 22:01:28 -0400

That's the stuff !!!  A man after my own heart ...

Between you and Markus you reached the sort of conclusion that you 
generally need to make this sort of thing fly and 235 array is
flying.

The MORT issue is solved by precomputing the array on boot, or at
key points if it is basically static for periods of time.

There are probably simple linear combinations to average or play
geometric mean games with 2 or 3 values bracketting the one you 
want that will give several digits of accuracy which is more than
enough for this if you want to get carried away. This is the usual
way to handle multiple degrees of freedom/variables though that is
always tricky.

For example, it might be that computations for MORT**2 were just
amort_factor[delay*2].

For fixed MORT amortize your solution is fine if you can guarantee 
the amort_factor is always <= 1 or there is a cap on benefit such
that benefit * amort_factor < 2^32 (maybe 2^31 signed).

This use of floating point I could grudgingly live with because the
analysis is relatively simple, painless and complete.

You could still use scaled ints as 
  benefit * amort_int[delay] / amort_scale
reducing yourself to probably 16 binary digits of accuracy, or more
if you could cap benefit.

Cheers,
RossW
=====

At 12:50 PM 02/04/16 +0100, Gregory Berkolaiko wrote:
>On 16 Apr 2002, Markus Linnala wrote:
>
>> "Ross W. Wetmore" <rwetmore@xxxxxxxxxxxx> writes:
>> 
>> > A good way to handle weighting functions is to make all your input
>> > calculations run in a fixed range, then pass the final result through
>> > an array lookup where the array is pre-computed for the set of values
>> > and that particular weighting function.
>> 
>> int amortize(int benefit, int delay)
>> 
>> I made quick test (added debug log and ran a game) and seems
>> that benefit had range 0 - 11857, but only had 1596 distinct
>> values. Delay had range between 0 - 396525, but effective range
>> was between 0 and 234 because if delay is big amortize goes to
>> 0.
>
>Since the result is benefit * something^delay
>all we need is precomputed array of 235 floats and then the code would be
>
>
>int amortize(int benefit, int delay)
>{
>  static float amort_factorp[235] = 
>    {1, 0.99, 0.976, ....}
>
>  if (delay < 0 || delay > 234) return 0;
>
>  return (int) benefit * amort_factor[delay];
>}
>
>where I have probably commited some capital crimes by treating FP number 
>improperly.
>
>
>This, however, does not provide the possibility of varying MORT, so I 
>guess it's of little use.
>
>G.




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