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: <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Re: server/settlers.c cleanup 3
From: "Per I. Mathisen" <Per.Inge.Mathisen@xxxxxxxxxxx>
Date: Sun, 14 Apr 2002 16:13:59 +0200 (MEST)

> 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.

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.

Yours,
Per

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




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