Re: [Repast-developer] RePast and extensibity

[Jason W. <jwo...@hb...>]

Thanks, Mark.  I look forward to taking a look at these APIs, and
chatting with you in person, when I get reconnected next week.

Have spent a little time with J/Link--makes me wonder how much of
the language can really be abstracted away without reinventing
Mathematica in XML, but I certainly think the issue of providing
access to RePast objects would be worth tackling.  As an example,
I use the Combinatorica package which does all kinds of graph-
theoretic stuff.  I've rewritten a couple of its functions in
Java to use with RePast, and would *love* to be able to just call
them directly by passing an ArrayList of DefaultNodes.  And even
if we don't end up with a truly cross-platform math/stat layer,
just having a consistent "Eval" semantics would be helpful in
hiding the various native interfaces.

Haven't looked at what you or Nick have done with trove or BCEL.
My simple SimHarness code, as you saw, uses Nick's original
Introspector class which works fine, though I agree it would be
nice to avoid reflection.

As for the "continuum of usability": my two cents here is that
the ideal way to accomplish this is to have a small number of
mechanisms that provide simple ways to do simple things, but
are also powerful enough to scale to more complex tasks--as
opposed to having "basic" and "advanced" ways to do everything.
But my sense is that this may come about through natural selection
as much as conscious design; people will do lots of experiments
with "advanced" things, and some of them may turn out to displace
their "basic" counterparts through common usage.  SimpleModel
seems like a classic example of this: it provides additional
functionality, doesn't take anything away, and simplifies the
code for probably 90% of the models people want to write.
Intermediate users don't have to "learn" SimModelImpl in the
sense of making a decision to inherit from it directly and
then having to rewrite whatever SimpleModel functionality
they still need.  I almost never extend SimModelImpl anymore;
I just override/ignore the SimpleModel functionality I want
to replace.  The HarnessModel thing I hacked up works the same
way--it's a drop-in replacement for SimpleModel that adds a
bit more functionality and tends to make common tasks easier
(for advanced users as well as novices).

Now I understand we are contemplating things that are *not*
drop-in replacements (e.g. scripting with Jelly, ant-based
build/install, etc.) which I agree are more prone to the
benefits of extra simplicity being outweighed by the costs
of an extra layer.  But here I think the main issue is a
point-in-time one: most of the costs are actually borne by
existing users who choose to migrate.  And to that I'd let
the economist in me respond: fine--as long as we don't force
anybody to migrate, well-informed users will only do so if
the benefits outweigh the costs.  If the new mechanism is a
pure benefit to new/future users (by reducing the learning
curve and/or providing additional power), it's guaranteed
to be a net gain.

Okay, I've tied up my in-laws' phone line long enough.
Have a good week!

     -j

jwo...@hb...
ja...@ee...
(617) 496-2079



On Sat, 16 Aug 2003 13:16:42 -0400
 "Mark R. Diggory" <mdi...@la...> wrote:
>In adition, I've been digging around in R/Omegahat, Matlab and Octave looking
>at their API's.
>
>http://www.omegahat.org/
>http://www.octave.org
>
>I think its interesting to see where all these projects are going in terms of
>Java development, cross language interaction and the exposure of their api's.
>One interest to me is defining a "subset" of functionality across all these
>applications that can also applies to commons math. I'm interested in the
>possibility of a "specification/api" that can be used to define
>statistical/mathematical evaluations in java. A generic api that one could
>write an evaluation in which could be executed against any provider, similar
>in nature to JAXP provides generic interfaces for xml parsers and transformers
>thats independent of their actual implementation.
>
>If there's anyone out there that might have information about if such an API
>already exists that would be great to hear about.
>
>-Mark
>
>Mark R. Diggory wrote:
>
>>Jason, I'm going to forward this back onto the list without the 
>>attachments, this is good stuff.
>>
>>Jason Woodard wrote:
>>
>>>Mark,
>>>
>>>Please excuse this private response to your recent repast-developer
>>>post.  I should probably post back to the list, but wanted to run
>>>these ideas by you first to see if you think I'm crazy.  I've also
>>>copied Gulya; he and I talked briefly about some of this stuff in
>>>Santa Fe last month.
>>>
>>
>>No this is great, I was unsure who around the Harvard Community was 
>>using RePast. We should really plan to get together once your back on 
>>the 25th.
>>
>>>I totally agree that RePast is reaching a limit in terms of
>>>integrating third-party functionality.  There is also an increasing
>>>demand in the modeling community for models that are themselves built
>>>from modular components.  For example, Gulya has the beginnings of a
>>>GA library that lots of people could benefit from if it were packaged
>>>appropriately.  I'm working on a library for network formation models
>>>that I'd like to make available for others to reuse and extend.  In
>>>fact, if we're really going to make cumulative scientific progress
>>>using ABM, it should probably become the norm that most models are
>>>designed this way, not just code intended to be used as a library.
>>>(This is orthogonal to the idea of "docking" to replicate results,
>>>which I also believe is important.)
>>>
>>>Maybe these are really two distinct problems--layers architecturally
>>>"above" vs. "below" RePast--requiring distinct solutions.  I don't
>>>have any experience with Geotools or Java3D, so I'm not sure I can be
>>>very helpful with the particular API / data structure mapping scheme
>>>you proposed.  (That said, I am looking for ways to link Mathematica
>>>and CPLEX to RePast models, so I would certainly be a consumer of such
>>>a pluggability layer.) 
>>
>>
>>I was looking into Mathematica online, they have a substantial "JNI" 
>>based API for Mathematica call J/Link.
>>
>>http://www.wolfram.com/solutions/mathlink/jlink/
>>
>>I think I'll be looking into this a little deeper. I've been working on 
>>a math/stat api at apache as well:
>>
>>http://jakarta.apache.org/commons/sandbox/math
>>
>>I think that there are some interesting features of this library that I 
>>can take to that project too. Specifically the "Eval" Class.
>>
>>
>>>But if you think it's worth thinking about the
>>>modular-model issue within the same scope, I would be very interested
>>>in collaborating.
>>>
>>>I've attached some code I cobbled together to explore the idea of a
>>>"harness" for RePast models, where a model can register modules it
>>>requires, whose build and step methods are then automatically called
>>>at the appropriate time.  The goal is to allow modules to be designed
>>>and used independently of a particular model.  I've used the new Java
>>>Preferences API to allow module (and model) parameters to be read
>>>from a single configuration file, and the new Logging API to allow
>>>modules to handle output in a flexible but consistent way.  I can see
>>>how your Jelly tag library could be used to tie everything together
>>>for scripting and batch mode execution.
>>>
>>
>>This is interesting, it reminds me of the nesting capabilities of Swarm. 
>>It is also an interesting "twist" on the work I've been doind with Jelly 
>>and BCEL. I might recommend that you look into the work that Nick has 
>>done with "trove" to handle some of oyu "reflection" based stuff going 
>>on in SimHarness. Trove and BCEL are both "bytecode" engineering 
>>libraries that can be used to generate "class wrappers" which call the 
>>method directly in the class instead of having to use reflection to look 
>>it up (this can be expensive in a simulation).
>>
>>I have some BCEL wrappers in my Jelly Project which basically provide 
>>dynamic "extension" wrappers on top of a a SimModel Implementation. This 
>>is how I can execute jelly script when a setup or begin method is called 
>>in the model. What this really provides is a "harness" that extends a 
>>user written model.
>>
>>>Speaking of which, another "itch" I've had for a while is the build
>>>and distribution process, both for RePast itself and for individual
>>>models. I know Gulya is wary of making things too complicated for
>>>non-technical users, but I think there's a real void here.  We are
>>>getting to the point where it's not unreasonable to expect people to
>>>have or install JDK 1.4 and Ant, and with those as a foundation many
>>>things are possible that would make it much easier for novices and
>>>experts alike, from simply getting the classpath right, to installing
>>>optional libraries, to deploying models as web applications.
>>>
>> > regards,
>> >     -j
>> > Jason Woodard
>> > jwo...@hb...
>> > ja...@ee...
>>
>>Theres a long standing argument about the amount of java technical 
>>experience a RePast model developer should have. Its a tough call, I 
>>think there should be "basic" and "advanced" tutorials and a "continuum" 
>>of usability. One of the big delema's I tend to see when 
>>researchers/developers are putting together these extensions to RePast 
>>that are supposed to "simplify" it for the user (like SimpleModel, your 
>>harenss, SimBuilder or my Jelly packages). The caution is that by 
>>"layering" these support classes ontop of RePast we risk breaking the 
>>continuum of usability so that the intermediate user has to learn new 
>>interfaces and API's to gain greater control over the model in thier code.
>>
>>Being able to call RePast from within an application such a Mathematica 
>>presents us with a really interesing situation because the rift between 
>>the two environments is a language one that would need to be spanned 
>>with something like JNI. There are alot of questions that arise - Would 
>>we to be able to provide all the functionality of a RePast SimModel, 
>>Controller and Schedule from within Mathematica? Would we want to 
>>provide bridges such that "Mathematica evaluations" coulds be executed 
>>from within the RePast model? Or would we want to provide more 
>>simplified access to one of these "hareness/wrappers" that we have develop?
>>
>>There are all kinds of discussions this can generate.
>>
>>-Mark
>>
>>>
>>>-----Original Message-----
>>>From: rep...@li...
>>>[mailto:rep...@li...] On Behalf Of Mark
>>>R. Diggory
>>>Sent: Tuesday, August 12, 2003 9:29 AM
>>>To: repast-developer
>>>Subject: [Repast-developer] RePast and extensibity
>>>
>>>
>>>I'm curious what others think about RePast in relation providing support
>>>
>>>for features such as Java3D and Geotools. I think we start to really 
>>>reach an unrealistic limit in terms of packaging all this 
>>>functionality directly into RePast as one monlithic project. It also 
>>>becomes questionable as to whether RePast gets added to GeoTools (or 
>>>any other Platform) or the other way around during this extension 
>>>process.
>>>
>>>Maybe it would be wise to begin a goal of defining a "plugability" layer
>>>
>>>for RePast such that the "core" features of RePast can be isolated 
>>>from the "extensions".  This way one can either use the "bare-bones" 
>>>of RePast in thier project without having to drag along all the 
>>>features they may not actually be interested in, or they can provide 
>>>an extension
>>>
>>>to RePast itself if it is acting as the framework.
>>>
>>>Mostly, these extensions tend to be isolated in the area of rendering. 
>>>But they do also involve mapping between various datastructures in 
>>>both RePAst and the Framework of question. It would be logical to 
>>>consider in
>>>
>>>the future that plugging RePAst into "X" platform will involve providing
>>>
>>>"Graphical" and "Nongraphical" bindings to and from that framework.
>>>
>>>
>>>      RePast                             Platform X
>>>
>>>
>>>1.) Implementatation of RePast space, graph or topology interfaces in 
>>>external API's for execution from within RePast.
>>>
>>>RePast Interfaces <-- Platform X Data Structures
>>>
>>>2.) Mapping model data structures to an external rendering engine.
>>>
>>>RePast Model Data Structures --> Platform X Rendering Engine
>>>
>>>3.) Exposing model controls and properties to external platform.
>>>
>>>RePast Model Properties/Controls <-- Platform X
>>>
>>>As we are starting to do to more of this "extension" these days. It 
>>>would be wise to begin such discussions while the interest is there. 
>>>This can happen at a couple of levels both internally to RePast with its
>>>
>>>own displays/controls and external to RePast in relation to GeoTools and
>>>
>>>other platforms that we are interested in "interfacing" with RePast.
>>>
>>>-Mark
>>>
>>>
>>>
>>>
>>>-------------------------------------------------------
>>>This SF.Net email sponsored by: Free pre-built ASP.NET sites including
>>>Data Reports, E-commerce, Portals, and Forums are available now.
>>>Download today and enter to win an XBOX or Visual Studio .NET.
>>>http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01
>>>/01
>>>_______________________________________________
>>>Repast-developer mailing list
>>>Rep...@li...
>>>https://lists.sourceforge.net/lists/listinfo/repast-developer
>>
>>
>>
>>
>>-------------------------------------------------------
>>This SF.Net email sponsored by: Free pre-built ASP.NET sites including
>>Data Reports, E-commerce, Portals, and Forums are available now.
>>Download today and enter to win an XBOX or Visual Studio .NET.
>>http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
>>_______________________________________________
>>Repast-developer mailing list
>>Rep...@li...
>>https://lists.sourceforge.net/lists/listinfo/repast-developer
>
>
>
>-------------------------------------------------------
>This SF.Net email sponsored by: Free pre-built ASP.NET sites including
>Data Reports, E-commerce, Portals, and Forums are available now.
>Download today and enter to win an XBOX or Visual Studio .NET.
>http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
>_______________________________________________
>Repast-developer mailing list
>Rep...@li...
>https://lists.sourceforge.net/lists/listinfo/repast-developer