[freeciv-ai] Re: (PR#7007) CM speedup patch: pruning on primary stat production

["Benoit Hudson" <bh@xxxxxxxxxxxxxxxxxxx>]

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

On Mon, Jul 19, 2004 at 07:58:54AM -0700, Jason Short wrote:
> I don't like it.  It seems to me that it embeds the assumptions the CM
> makes even deeper.  And I want to remove some of those assumptions.
>
> These assumptions include:
>
> - Workers may only produce primary stats.
> - Specialists may only produce secondary stats.
> - Specialists may only produce _one type_ of secondary stat.
>
> I certainly want to remove the third assumption; this is needed for an
> SMAC-like compatability mode.  I hope to remove the second assumption;
> this is needed for a MoM or MoO-like compatability mode.  I'm not sure
> about the first assumption but I suspect that if the second and third go
> it will be of little use.

The current CM code assumes:
   (food, shields, trade) = f(sum of worked tiles)
   gold = f(trade, taxmen)
   sci = f(trade, scientists)
   lux = f(trade, elvises)
(where 'f' means 'function of' but not all the same function).

Furthermore, it assumes that all the functions are monotone increasing,
and that the evaluation function (the 'factor' fields) is itself
monotone increasing.

My patch was adding the assumption that
        food = f(sum of food on worked tiles)
etc.  The current code says that it doesn't matter which tiles you use,
all that matters is when you sum their food/shields/trade.  But then the
food surplus might at the moment depend on all three of f/s/t that you
produce from tiles.  My code was going to encode the fact that in civ1/2
and CTP, food surplus does not depend on shields or trade produced.  I
don't know MoM, but MOO/MOO2 had this assumption as well, locally for a
city (although there were complications with shipping food around and
selling the galaxy-wide surplus).


The thing that makes the biggest difference, computationally, is the
monotone-increasing assumption.  Caching is also important, but much
less: it reduces big constant factors rather than big asymptotics.  The
more assumptions about independence of the production types, the better
we can cache results without calling real_fill_out_result and thus
generic_city_refresh.  But we can probably do better in other ways.

        -- Benoît