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

[freeciv-ai] Re: server/settlers.c cleanup 3

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: <freeciv-ai@xxxxxxxxxxx>
Cc: "Ross W. Wetmore" <rwetmore@xxxxxxxxxxxx>
Subject: [freeciv-ai] Re: server/settlers.c cleanup 3
From: Per I Mathisen <per@xxxxxxxxxxx>
Date: Wed, 17 Apr 2002 08:28:11 +0200 (MEST)

[moved to freeciv-ai]

On Tue, 16 Apr 2002, Ross W. Wetmore wrote:
> The condition and the arithmetic calculation may or may not give quite
> the same result depending on the exact order of computation and complexity
> of the expressions.
> To be blunt, the hassles with this are not worth the trouble of changing
> amortize to be correct to the 10th vs 9th decimal place when the results it
> returns are seldom even valid or would change game behaviour at the 1st.
> My firm recommendation is to drop all efforts to modify the current
> amortize, and certainly not use FP anywhere in the code.

Ross, you obviously know a great deal more about floating point than me,
but we're talking about a freakin' _two lines of code_ here. Don't bring
out the big drums.

If it is the decimals in the return value you are worried about, then let
us just pass it through floor(). Notice how no-one has suggested letting
amortize return a floating point value.

  assert(delay >= 0);
  delay = MIN(delay, 999);
  benefit = MIN(FC_INFINITY, benefit);
  amortval = pow(((float)MORT - 1) / MORT, delay);
  return floor(benefit * amortval);

Please point out to me how the above could possibly fail (the assertion
excepted, and given that zero is a valid return value).


"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]
  • [freeciv-ai] Re: server/settlers.c cleanup 3, Per I Mathisen <=