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

["Ross W. Wetmore" <rwetmore@xxxxxxxxxxxx>]

At 04:13 PM 02/04/14 +0200, Per I. Mathisen wrote:
>> On Sun, Apr 14, 2002 at 01:12:29AM -0400, Ross W. Wetmore wrote:
>> > Wait until your program dies consistently storing its float value back
into
>> > an int. Mixing the two properly is very hard to do, moreso when most
>> > programmers never really used floating point and don't understand it.
>> >
>> > Amortize, and some of those screwball overflow functions will probably
>> > get most freeciv games this way somewhere in the endgame play.
>
>Thanks for pointing this out. I didn't know. But the solution seems
>simple: cap input values at reasonable values.

No! Convert the entire routine to run in floating point, and check the 
output values before storing them back into a return int. Complete
isolation of the FP part is the only valid solution, unless you want
to test every store operation in the routine for correctness.

This is not the only FP issue. 

The time savings are negligible, but more man hours have been spent
fighting the amortize function battle than any other piece of code
- I think this is the 4th or 5th round I know about.

Amortize should be replaced anyway ... it is really an unnecessary
weighting function, the accuracy is totally irrelevant and the 
devloper time savings for better things would be a significant 
fraction of the ongoing effort.

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.

>On Sun, 14 Apr 2002, Raimar Falke wrote:
>> I agree with Ross. We don't want to open another can of worms.
>>
>> I have no problem if you write the float version of amortize into a
>> comment.
>
>No, Raimar. You miss the entire point of the rewrite. It is not to get
>readable code, but to be able to dynamically change MORT. This is the AI's
>patience, and at present is has constant patience no matter which
>situation it is in. The current amortize will only work if MORT is 24.
>This is wrong.
>
>Will it be ok if I cap the input values and test this function with
>respect to all possible combinations of input values? That way there
>cannot be an error in this part of the code. I will do similar
>statistical testing for dynamic mort, when I get around to that.

Statictics don't matter. To fix the bugs you needed to test ALL possible
values - this should keep you busy for the forseeable geologic age :-).

>Yours,
>Per
>
>"Treason doth never prosper: what's the reason?
>Why, if it prosper, none dare call it treason."
> -- Sir John Harrington (1561-1612)