I think someone already said this, but here's an easy way to make self-modifying go down easier. Think of an agent that has a built-in genetic programming system. It uses that system to generate a better set of rules for itself, which it then adopts.
That seems both a lot like what we as people do and not so far out as an agent-based modeling framework. That's essentially the requirement -- or at least one of my requirementss. We are going to do our best to build it -- probably the old fashioned way, in Java. -- Russ On Sat, Aug 29, 2009 at 10:36 AM, Nicholas Thompson < [email protected]> wrote: > Steve, > > funny, I have an icechest like that, too. Except that mine is in > masschusetts. > > Notice that there is that that odd copula "self modifying"; I suppose I > should get my own damned thread, but some time, I hope we can discuss that > idea because, like "self-destroying concept", I think "self-modifying" agent > is a self-destroying concept". Or perhaps it's just an oxymoron. > > > > Nicholas S. Thompson > Emeritus Professor of Psychology and Ethology, > Clark University ([email protected]) > http://home.earthlink.net/~nickthompson/naturaldesigns/<http://home.earthlink.net/%7Enickthompson/naturaldesigns/> > > > > > > ----- Original Message ----- > *From:* Steve Smith <[email protected]> > *To: *The Friday Morning Applied Complexity Coffee Group<[email protected]> > *Sent:* 8/29/2009 11:16:14 AM > *Subject:* Re: [FRIAM] Agents, stocks, and flows > > Doug - > > I think you suggested specifying and designing a system from requirements > and something like first principles (which I think is a really good way to > approach actually solving the problem). > > I suggested a review of the *real world* (not computer systems and models) > for networks of entities which are self-modifying in the sense of Russ's > quest. I think the answer is (probably) that there are many if we admit > long enough time scales (referencing Marcus' comment, the time scale of the > evolution/modification of the network itself has to be much longer than the > dynamics of the network to avoid "evolutionary meltdown). > > I've got an ice-chest full of beers and melting ice if you have time to tip > one later today. > > - Steve > > > > > On Sat, Aug 29, 2009 at 10:53 AM, Steve Smith <[email protected]> wrote: > >> >> >> I wonder if the combined genius, memory, attention, focus of this group >> can come up with real-world systems which (obviously) seem to work this way >> (require this level of abstraction/complexity to model). >> >> -Steve >> >> >> I thought I suggested this yesterday... > > *"Has anybody just tried to design this application the old-fashioned way; > i.e., develop a set of requirements that > * > > - *define the interactions between the components of the system,* > - *identify (clearly, no vagueness allowed) the desired results from > running the simulation, > * > - *identify (clearly, no vagueness allowed) the inputs for the > simulation, and* > > **then* determine what design best fits the application? > > [Blah Blah Blah]" > > * > --Doug > > ------------------------------ > > ============================================================ > FRIAM Applied Complexity Group listserv > Meets Fridays 9a-11:30 at cafe at St. John's College > lectures, archives, unsubscribe, maps at http://www.friam.org > > > > ============================================================ > FRIAM Applied Complexity Group listserv > Meets Fridays 9a-11:30 at cafe at St. John's College > lectures, archives, unsubscribe, maps at http://www.friam.org >
============================================================ FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College lectures, archives, unsubscribe, maps at http://www.friam.org
