Complete.Org: Mailing Lists: Archives: freeciv-dev: December 2001:
[Freeciv-Dev] Re: [PATCH] advdomestic.c cleanup (PR#1149)
Home

[Freeciv-Dev] Re: [PATCH] advdomestic.c cleanup (PR#1149)

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Petr Baudis <pasky@xxxxxxxxxxx>
Cc: Mike Kaufman <mkaufman@xxxxxxxxxxxxxx>, freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: [PATCH] advdomestic.c cleanup (PR#1149)
From: Chris Richards <chrisr@xxxxxxxxxxxxxxxx>
Date: 23 Dec 2001 13:41:20 -0600


Petr Baudis <pasky@xxxxxxxxxxx> writes:
> Dear diary, on Sun, Dec 23, 2001 at 06:22:18PM CET, I got a letter, where 
> Chris
> Richards <chrisr@xxxxxxxxxxxxxxxx> told me, that...
> > It can be further reduced to:
> > 
> >    cost = (amortized * weight) / (MAX(0, weight - amortized));
> > 
> > except that you are incurring round-off error from amortized results in cost
> > being 1 less (integer-wise) than with the old formula.
> > 
> > Not knowing how round-off was playing a part in the previous heuristic, I
> > can't common on which cost is better.
>
> I disagree here. First, division-by-zero smiles to you from that expression,
> and second, (amortized * weight) / (1/64) is same like (amortized * weight) *
> 64. I wouldn't reduce that to zero then.

No, perhaps not.  By you will get a floating point exception trying to
perform the operation 10 / (1/64) even if it is the same as 10 * 64.
That was my overly subtle simplification.

My second point about the original formula and the reduced formula
(i.e., factoring out 64 from weight before sending it into amortize())
still applies.  The computed cost will be 1 less due to round off
error.  You can't factor out the 64 from weight without getting a
different amortized result that will not scale back by multiplying 64.
The loss of precision due to integer math is a real factor.

Cheers,
cjr


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