Eclipse Community Forums: AMP » Recurion in Acore (Francesco Parisi)

Help

Home

Home » Archived » AMP » Recurion in Acore (Francesco Parisi)

Show: Today's Messages :: Show Polls :: Message Navigator

Recurion in Acore (Francesco Parisi) [message #495760]

Thu, 05 November 2009 22:51

Miles Parker

Messages: 1341
Registered: July 2009

Senior Member

A message I received from Francesco Parisi. Francesco, I hope you don't mind me copying it here..

Quote:

Dear Miles,

I have a question about metaABM agents behaviour that, in turn, could be
interesting for Acore too.

It seems to me that it is not possible to define a behaviour of the
following type "do rule (activity) X until condition C is verified". Right?

In declarative languages, loops are commonly achieved by admitting (some
form of) recursion, but if I understood, recursion is not possible with
metaABM rules.

This looks to me as a weakness of the expressive power of metaABM language.
If it's so, do you think this could be an interesting extension of Agent
Modeling Framework "Acore" meta-model?

Clearly, users can edit java instruction in a "method" rule, but this is not
my question, since I'm thinking about the structure of metaABM rules, not
about what users can specify by java language.

What do you think about this issue?
Looking forward to hearing from you,

Francesco.

Francesco Parisi
Ing. Francesco Parisi, Ph.D.
Dipartimento di Elettronica, Informatica e Sistemistica (DEIS)
[snip]
Web: http://wwwinfo.deis.unical.it/~parisi/

Francesco, I think that you have made a good case for some kind of clear support for this and that probably existing approaches are not useful. I'm also pretty convinced that this shouldn't be an extension but actually in the main meta-model proper even though it potentially creates some issues. (And, clearly just punting off to Java is not really a solution.)

Here is a bit of background. First I'm sure you already appreciate this, but I should say that MetaABM is not intended to be a general purpose language at all; it is designed to use what we know about the domain and usages to gain great leverage into one set of problems. Further extensions that allow more generality are of course always available. But at the same time, we shouldn't use this as an excuse in itself not to be as general and useful and expressive as we can. OTOOH, there is I think some value in representational contrasts for their own sake in some cases. For the MetaABM design I was being explicitly very "anti-loop" for architectural and philosophical Smile

reasons. And I got a lot of push-back on that as you can probably imagine.

Re: architecture, removing explicit loop structures has an enormous set of advantages. As a commonly known example, in SQL I think it's fair to say that not having the recursive and loop structures to worry about allowed a lot of really interesting dynamic compilation techniques etc., and so my thinking was that not having them in ''general'' would allow that kind of thing to develop spontaneously. I also have issues with designs that require a lot of loop constructions, say in searching a space, and as people using tools often naively go to that approach by default, simply not providing for it would prevent that. Because after all, an ABM scheduler is simply the ultimate loop making machine, it just does it over time, and my experimental thought was that you could do everything you really needed to do by exploiting that fact. And that means that I can respond to your question:

Quote:

It seems to me that it is not possible to define a behaviour of the following type "do rule (activity) X until condition C is verified"

With a "no, it actually is possible", but I've be being pedantic. With MetaABM you can in fact define a rule that does just that. It would look like this (in Sugar pseudo-code):

MyRule :
[Verified :- Query C,
ActivtyX :- Verified->Do something]

The reason that this probably isn't satisfying to you Smile

is that each invocation happens over time. Now I'd argue (below) that everything happens over time, but that's again a philosophical argument, not a practical one. And anyway to do this properly, we'd need a much more sophisticated model of time.

And then this leads into philosophical issues that have to do with computation and mathematical analysis (not to mention post-structural arguments) in the context of modeling complex systems in general. Too much to say about that here, and I know that I am risking sounding like a crank. Smile

But in brief, I find that many so-called ABM models end up being a bunch of traditional equation approaches dressed in (thin) ABM clothes. Now, I don't have a problem with that at the ultimate level -- equation approaches are very useful -- but I wanted to sort of force things into a higher level of representation (as I'll capture on Wiki, a high level functional approach is most appropriate for some of this) again by actually preventing an easy answer / work-around. And (this is the controversial part) I'm not so sure that loop and recursive structures are really explicit/direct features of natural systems. It seems to me that they are more higher level description and appreciation of the outcome of those systems over time. For example, genetic structures seem highly recursive and self-referential, but that is a higher-order outcome of micro interactions that are much more mechanistic. Analogously, in the social science realm we are finally convincing people of how economic and political decision making is bounded heuristics and not high-level optimization. OTOH, there may be systems that I'm not thinking of that do have these immediate characteristics, and there is no question that they can be well approximated using recursive and loop structures.

But that argument is moot. What I think about this isn't really the issue, it's what everyone wants to be able to do with the tool, and one outcome of the experiment of MetaABM is to convince me that an explicit goal of Acore should be to not just represent ABMs, but also equation and systems dynamics and statistical models in as general and transformable way as possible.

I've put your suggestion on the Wiki, and I hope it engenders a lot of dialog.

thanks very much,

Miles

Report message to a moderator