Complete.Org: Mailing Lists: Archives: freeciv-dev: April 2005:
[Freeciv-Dev] Re: (PR#12834) amortize()
Home

[Freeciv-Dev] Re: (PR#12834) amortize()

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
Subject: [Freeciv-Dev] Re: (PR#12834) amortize()
From: "Brian Dunstan" <bdunstan149@xxxxxxxxx>
Date: Mon, 18 Apr 2005 16:22:18 -0700
Reply-to: bugs@xxxxxxxxxxx

<URL: http://bugs.freeciv.org/Ticket/Display.html?id=12834 >


--- "Per I. Mathisen" <per@xxxxxxxxxxx> wrote:
> 
> <URL:
> http://bugs.freeciv.org/Ticket/Display.html?id=12834
> >
> 
> On Mon, 18 Apr 2005, Brian Dunstan wrote:
> > I noticed that the amortize() function uses a very
> > clever, but complicated, algorithm.The reason
> > apparently is to save time.If that is the purpose,
> > why not use a more transparent, but slower
> algorithm,
> > and use it to make a lookup table?
> 
> It would be a rather large table. Input values can
> be large. I don't know
> if amortize calls can be factored.
> 
> In any case, I really doubt this has much effect on
> the overall speed.
> 
>   - Per

Yeah, speed would not be affected much.  The benefit
would be simplicity, and the ability to change the
interest rate.  

The table would be the value of a benefit of
BENEFIT_FACTOR (say, 1000), t turns in the future.  So
you could do

(amortization_table[t] * this_benefit) /
BENEFIT_FACTOR

where the amortization_table array has a few dozen
elements; maybe if you feed amortize something like
amortize(500, 100), it should return zero, since the
AI should not be making decisions on things 100 turns
in the future.


Brian


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 





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