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

[Raimar Falke <rf13@xxxxxxxxxxxxxxxxx>]

On Thu, Jul 18, 2002 at 10:55:52PM -0400, Ross W. Wetmore wrote:
> 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 :-).

You want to add flexibility to the code base. The changes have an
unknown size. These changes are only required for the AI development.

> >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.

Than why do you want any changes to the architecture at all? You can
just continue clean up the AI code.

> >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.

You keen repeating that the agents are GUI-helpers. This isn't the
goal. But I agree that from the current code one may get the
impression of GUI-helpers. Hopefully time will show that a real AI
emerges.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "Life is too short for reboots."