[freeciv-ai] Re: time table for ai restructuring

["Ross W. Wetmore" <rwetmore@xxxxxxxxxxxx>]

At 07:41 AM 02/07/17 +0200, Raimar Falke wrote:
>On Wed, Jul 17, 2002 at 12:31:40AM -0400, Ross W. Wetmore wrote:
>> I don't think we are fundamentally at odds here. Using the common code
>> base to do a lot of this makes sense. Updating or rewriting the common
>> code to do it better in spots (if needed) and using that is not much 
>> different. When the AI runs as its own process it should reuse as 
>> much of the current code as it can wherever it gets it. The same applies
>> to the process along the way.
>
>> I have no problem running multiple instances of parts of the common code
>> (i.e. for each AI) inside the server process, at some point in the process.
>> I have no problem not doing it - it becomes an implementation detail.
>
>I have a problem with this. It requires a lot of changes to common/
>and server/. And for what? For an intermediate step. 

Why should the changes be intermediate. I would think this would be an
opportunity to cleanup things so they would run in a number of different
environments when one ran across a problem area, and to remove some of 
the more restrictive elements of the current codebase that limit options.

But the "problems" are really only from limited imagination that thinks
of a bad way first, or doesn't think, and then can't presume, or admit, 
there might be easier and better ones :-).

>The real goal is
>IMHO a real seperation of the address space. 

Right, and that has little to do with moving code to a client process.

>Than the AI and the
>server can communication either with shared memory, RPC or
>packets. Packets are the obvious choice here. Seperate process and
>communicating with packets ... sounds like a client.

But the separate process is the unnecessary step that can be deferred
while one maximizes the work done with the current codebase where 
things can be developed and tested in modular steps.

>So far I would prefer Pasky's approach: clean up part for part and
>move it to the client. 

Again, you add these unnecessary extra bits like move to the client
that make the AI task harder not easier.

>And in parallel the cleaned up parts are put
>back into the server AI. Than you have always a working server AI
>which should become better and you can test your cleaned up code.

But to test a working server AI in a separate address context you
need to separate its calls into the server code and vice versa. 
That is a different process than cleaning up routines that are 
already localized in context.

And in doing that for an AI, you need to deal with the concepts of
local per-AI data and incomplete data. These are the big tasks for
an AI project vs a GUI helper tool.

Moving the AI to the client requires a big effort to resolve a number 
of critical path issues up front, rather than tackling them bit by 
bit. Only minor utility stuff can move to a client context right now.

Client AIs will be quite stupid relative to the current server AI for
some time as they build up their codebase to match the server AI's.
So it is to the advantage of those pursuing an evolutionary server
migration to not move to a client context until the big issues with 
the server are resolved to the point where it can run there with
just a little hop.

>       Raimar
>-- 

As I say, the agent and the real AI task are approaching things from
two quite different positions and they are not the same thing.

The agent work will probably never make a good AI as well. Modelling
human thought processes and tailoring your tools to deal with human
ways of seeing or approaching problems really makes for poor and
inefficient AI compared to things one can do if one doesn't have to
work at things through these constraints.

For example, the AI could use a Simplex algorithm to optimize all city 
resource allocations as a whole. This is far more efficient than some 
sort of CMA iterative process required because one has to deal with 
individual cities one at a time using input values designed for human 
comprehension or control function constraint.

Cheers,
RossW
=====