Home » Modeling » AMP » Recurion in Acore (Francesco Parisi)
|Recurion in Acore (Francesco Parisi) [message #495760]
||Thu, 05 November 2009 17:51
| Miles Parker
Registered: July 2009
A message I received from Francesco Parisi. Francesco, I hope you don't mind me copying it here..
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
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,
Ing. Francesco Parisi, Ph.D.
Dipartimento di Elettronica, Informatica e Sistemistica (DEIS)
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 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:
|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):
[Verified :- Query C,
ActivtyX :- Verified->Do something]
The reason that this probably isn't satisfying to you 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. 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,
Current Time: Tue Jul 22 11:33:56 EDT 2014
Powered by FUDForum
. Page generated in 0.02307 seconds