Complete.Org: Mailing Lists: Archives: freeciv-ai: November 2004:
[freeciv-ai] Re: (PR#8992) Patch: Building ferries
Home

[freeciv-ai] Re: (PR#8992) Patch: Building ferries

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: undisclosed-recipients: ;
Subject: [freeciv-ai] Re: (PR#8992) Patch: Building ferries
From: "Gregory Berkolaiko" <Gregory.Berkolaiko@xxxxxxxxxxxxx>
Date: Mon, 8 Nov 2004 22:09:00 -0800
Reply-to: rt@xxxxxxxxxxx

<URL: http://rt.freeciv.org/Ticket/Display.html?id=8992 >

> So, a simpler feed-back system instead. I'm sympathetic to a simpler
> approach. I'll try a feedback control system.

The patch is very nice.  I have some minor corrections, but we can do them
later.  We need to discuss the logic of selecting the number of boats to
be built.

I played with your patch lots and found some problems.

Your formula is:
        (0.6*B - A)/3 + (P/B - 0.7)/4 + 0.5,
where B = total number of boats, A of them free (available), P is the
number of passengers waiting on the shore (does not include passengers
already on board, does include passengers that are being built, scaled).

This formula is dimensionnally incorrect: the left part is in boats, the
right part is in passengers/boats.  One symptom of this is the following
behaviour:
* there are 4 boats going to pick up 4 passengers (P=4, B=4, A=4)
the result is 0.04 and no new boats will be built
* now all 4 boats picked up their passengers (P=0, B=4, A=0)
the result is 1.125 and 1 new boat will be built

but the situation did not change in any real way!  there are no additional
passengers and when the current four will be delivered, the new boat (and
the old ones) will be unemployed.

This is the problem with the complicated approach, small calculations are
piled up, they are hard to debug (too many constants can be tweaked) and
people who come after us spend time trying to understand them (this
doesn't apply much to your code which is well documented).

Let me now defend my original formula.  First of all, available boats and
passengers should cancel each other at the exchange rate 1-to-1, otherwise
a situation like above will arise.  Next, future passengers will come in
the future (if at all) when currently engaged boats will free up, so they
should be compared with the total number of boats.  I also thought that
the ratio 1 boat - 2 customers (either one on board or both waiting on
shore) is about right.  This lead me to
+    /* WAG rules: idle boats count twice, future passangers
+     * count as half */
+    psngrs = psngrs * DENOM + MAX(0, future_psngrs - boats * DENOM);
+    boats = (boats + avail_boats) * DENOM;
+    boats_to_be_built = (psngrs > boats ? 1 : 0);

If we remove the DENOM, which is there to make arithmetic integer, the
formula is

if    P - A - B + max(0, FP-B) > 0,   we need more boats.

We _can_ introduce a tuning parameter into the equation,
        P - A - B*alpha + max(0, FP-B)
here alpha is like the "target queue" that you are using.

I think building more than one new boat at a time is needed very rarely
and is quite risky because we react too much to a potentially
short-lived surge in the demand.

If you still want it, I suggest we formulate the question as "find
the minimal integer n such that P - (A+n) - (B+n)*alpha + max(0, FP-B) is
negative" (meaning "how many boats should we build to stop asking for
more")

the formula for n is  then
  (P - A - B*alpha + max(0, FP-B)) / (1+alpha)
rounded up.

But this is relatively minor problem.

Now, the major problem is to adapt the patch to use the channel code by
Per.  It will significantly alter the whole structure but should make the
code faster.  A big part of the task is to actually make Per's code
correct ;)  I will try to do it tomorrow.

Another thing we need to do is to influence technology.  If we don't know
Map Making, the ferry code should ask for it.


Damn, I spent 2 hours writing this email :(((

Hope to be back tomorrow,
GB




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