[Freeciv-Dev] Re: More agent code

[Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>]

On Mon, Sep 24, 2001 at 07:38:56AM -0700, Raahul Kumar wrote:

[ You still don't quote the lines I wrote. ]

> Raimar
> 

> Can you please write up the 3 functions below in mathematical terms
> please.  Similar to how you explained try_to_find_primary earlier. I
> may want you to illustrate it with an example city, similar to the
> way I approached apply_result_on_server.  I want a better
> explanation of 3) calc_fitness in particular.

> I REALLY do not like the way you coded try_to_find_primary. My
> problem lies in your description below which I find
> a.) circular logic
> b.) unnecessary

The description:
/*
 * Tries to find a worker allocation scheme which meets the required
 * surplus of food, shield and trade. Will use the amount of given
 * workers. Will use the remaining people as entertainer. Will fill
 * out the whole result with the solution found or
 * result->found_a_valid=0.
 */
is ok.

> These are the food and shield upkeeps and the corruption. Since
> these values depend on the actual production (which is unknown at
> this time) we have to estimate these based on the current differnce
> between production and surplus.
> 
> ms - minimal surplus
> mp - minimal production
> u  - upkeep or other factors which decrease the production, depends on the 
> base
> 
> production
> s  - surplus
> p  - actual production
> 
> s = p - u(p)
> 
> -> mp = ms + u(mp) 
> 
> Problem: we don't know mp yet
> This is no real problem because we will just do a full calculation of
> the city (in fill_out_result) and test afterwards if we got the
> required surplus.
> 

> Then WHY THE HELL are you calculating mp = ms + u(mp) if it is
> unnecessary. I'm either misundertanding what you have written above
> or you have made a boneheaded mistake. Will send you either code
> patches or tell you the functions below are as good as they're gonna
> get.

For the optimize_worker we want production hints. try_to_find_primary
will several production hints. The main loop in try_to_find_primary is
an incremental algorithm. It will also find the a valid result if we
start with random hints. A better starting position are the minimal
productions. We can't exactly calculate this minimal production but
there is a approximation. So try_to_find_primary should be faster
(less tries) if there is a valid result.

>  maximize_trade

For the optimize_worker we want production hints. maximize_trade gets
a set of minimal surplus of food, trade and shields. It will also get
a set of production hints which are valid (will provide the minimal
surplus). maximize_trade will now increase the production hint for
trade since it hopes it will get more trade. It first tries a very
large increase for the production hint for trade. If this didn't give
a valid result if will increase the production hint for trade step by
step till the required surpluses can't be meet anymore.

> test_extra_trade

It adds a given extra amount to the production hint for trade and
tests if a valid solution can be found.

>  calc_fitness

I can't write it more clearly than it is already written in the C
code. What is your question?

>  For example the goto agent will have to handle all unit types (air units with
> refilling,
>  trireme,...) and the settler management need a GUI interface.
>  

> I'm volunteering to try extending the goto agent. You're on your own
> with the GUI's. Freeciv just supports far too many fricking guis. I
> suggest a gui cull. Do you have any ideas about airplanes? I'm
> inclined to rulechanges to make aircraft almost identical to ground
> units as far as the AI is concerned. Fortunately the freeciv-dev
> lists has had a lot of email on how to handle tri-remes.

Yes aircrafts should have the same interface. The Dijkastra has to be
modified in a very similar way to handle the trireme:
 - can_unit_type_move_from_to has to be modified to take into account
 a trireme which may sink and an airplane which may run out of fuel
 - in addition to the 8 directions there is another action possible:
 wait for next turn. You can think of a loop on the current node of
 the graph.
 - an extra variable for the available fuel has to be implemented

>  In the long term the server should contain no AI code. There are two
>  large problems with this:
>   - the client side ai code has to be at least as good as the server ai
>   code
>   - there has to be a mechanism on the server side which
>   spawns/activates a helper (gui-less) client
> 
> The client side ai code can easily be far better than the server AI
> code. In fact with the current duplication of code it would be easy
> enough to have the client AI play the server AI! Once the client AI
> can successfully beat the server AI no more need for it.
> 
> I thought there was already a gui-less client. Isn't it gui-stub? 
> Obviously there is more required. Please say what is missing from
> gui-stub that you need.

No gui-stub is a template for new clients. There are some parts
missing for a general gui-less client. However this isn't a top
priority project since it is hard to debug agents without the
information the gui provides.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "I do feel kind of sorry for Microsoft. Their attornies and marketing
  force must have tons of ulcers trying to figure out how to beat (not
  just co-exist with) a product that has no clearly defined (read
  suable) human owner, and that changes on an hourly basis like the
  sea changes the layout of the sand on a beach. Severely tough to
  fight something like that."
    -- David D.W. Downey at linux-kernel