repast-developer

Re: [Repast-developer] Controller hierarchy

[Skye Bender-d. <sky...@st...>]

Hi nick, and folks,
   Was just remembering a conversation we had a long time ago about 
the idea of a ParameterSpaceExplorer, which seems relevant to the 
controller discussion.

Crudely, the idea is pretty much the same as doing runs from a batch 
file, but the batch file has a GUI and data presentation of its 
results.  So after someone has finished coding a model, and wants to 
explore "results" over a particular range of parameters, they could 
load the ParameterSpaceExplorer, enter the range, parameter sampling 
density, and number of repetitions per point, and come back in a 
couple of hours to a nicely collected data set.  Of course this 
requires that models have well defined stopping conditions (or a set 
number of steps), and report clear numeric results of some kinds.

In the (rare) case where there are two main input parameters of 
interest, and one result parameter, we could have nice 2.5D plots of 
results, or if multiple result params, allow switching between result 
plots...    Could also calc "pseduo"-error ranges and stdv.   Then 
the user can say, "hmm, what's this discontinuity on the graph, is it 
just randomness?  lets do another 300 runs, more closely spaced along 
parameter-x, and see what we get..click click.."

Another advantage is that it might help people (us model coders) 
focus their (our) thinking on "OK, what are my inputs, and what are 
my results, and what does it mean" instead of just, "WOW! isn't that 
pretty!"  I don't by any means mean to dis good graphical 
representations of a sim, as I think they are incredibly important, 
but I think it is also good to help formulate a "question" and 
"results" approach as well.

I know it is better to do things than suggest them, but I've got all 
the java I can handle at the moment with this network stuff.  But I 
thought I'd throw the idea out there again, just in case coordination 
between DataSource, DataRecorder, and the Controller interface might 
be useful or necessary in the future...

cheers,
   -skye

>
>I refactored the controller (small c) hierarchy over the last few days.
>The point here was to isolate the basic semantics of a controller in an
>Interface. This new Interface is IController and the basic semantics
>have to do with the execution of a model, starting, stopping etc.
>BaseController implements these semantics, and retains backward
>compatibility with all its weird little utility methods.
>BatchController and AbstractGUIController add different ways of dealing
>with parameters and Controller adds an actual GUI (buttons and so forth)
>on top of AbstractGUIController. I'd rather do this with wrapping, but
>it was easier to preserve backward compatibility w/r to Controller this
>way. Wrapping can be revisited later.
>
>just to keep y'all in the loop,
>
>Nick
>
>--
>Nick Collier
>Social Science Research Computing
>University of Chicago
>http://repast.sourceforge.net
>
>
>
>-------------------------------------------------------
>This sf.net email is sponsored by:
>With Great Power, Comes Great Responsibility
>Learn to use your power at OSDN's High Performance Computing Channel
>http://hpc.devchannel.org/
>_______________________________________________
>Repast-developer mailing list
>Rep...@li...
>https://lists.sourceforge.net/lists/listinfo/repast-developer


-- 
--------------------------------
Skye's fone/Vmail: 650.853.0679
--------------------------------

[Repast-developer] Controller hierarchy

[Nick C. <nic...@ve...>]

Hi,

I refactored the controller (small c) hierarchy over the last few days.
The point here was to isolate the basic semantics of a controller in an
Interface. This new Interface is IController and the basic semantics
have to do with the execution of a model, starting, stopping etc.
BaseController implements these semantics, and retains backward
compatibility with all its weird little utility methods. 
BatchController and AbstractGUIController add different ways of dealing
with parameters and Controller adds an actual GUI (buttons and so forth)
on top of AbstractGUIController. I'd rather do this with wrapping, but
it was easier to preserve backward compatibility w/r to Controller this
way. Wrapping can be revisited later.

just to keep y'all in the loop,

Nick

-- 
Nick Collier 
Social Science Research Computing 
University of Chicago 
http://repast.sourceforge.net

Re: [Repast-developer] sim.gui.Display3D

[Nick C. <nic...@ve...>]

Great. One change is that displays are now resizable by dragging the
frame. By this I mean that everything in the frame is resized
appropriately (agent's display larger or smaller etc.)

Nick

On Tue, 2002-12-10 at 11:29, Phil Feldman wrote:
> Hi All,
> 
> I'm looking at adding a 3D display surface to the RePast code I'm 
> working on. I've done quite a bit of work with the Java3D api, and it 
> seems reasonably speedy and stable.
> 
> Since J3D requires a Canvas3D, and anything drawn in the 3D space is not 
> compatable with awt or swing drawing routines, I'm assuming that the big 
> changes required will be in sim.giu.SimGraphics, sim.gui.DisplaySurface, 
> and the classes they touch. As such, before I get started, I'd like to 
> know if there is going to be any significant change to the display 
> system in 2.0 that I should take into account? Also, I'd like 
> suggestions as to which other classes I should be aware of.
> 
> Thanks,
> 
> Phil Feldman
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Repast-developer mailing list
> Rep...@li...
> https://lists.sourceforge.net/lists/listinfo/repast-developer
-- 
Nick Collier 
Social Science Research Computing 
University of Chicago 
http://repast.sourceforge.net

Re: [Repast-developer] sim.gui.Display3D

[Thomas R. H. <th...@sr...>]

That would be fantastic.  There haven't been any major changes to the
gui stuff in 2.0, but we might be doing some refactoring this week.  I
can't tell you exactly what, because we haven't quite decided.  Anyhoo,
as soon as we make that decision, I'll let you know.  That having been
said, there have been some changes to things like menus, as well as some
name changes.  My suggestion would be to checkout the cvs version of the
gui stuff.  Hopefully, not too much will change in there before release
:).

-Tom


On Tue, 2002-12-10 at 10:29, Phil Feldman wrote:
> Hi All,
> 
> I'm looking at adding a 3D display surface to the RePast code I'm 
> working on. I've done quite a bit of work with the Java3D api, and it 
> seems reasonably speedy and stable.
> 
> Since J3D requires a Canvas3D, and anything drawn in the 3D space is not 
> compatable with awt or swing drawing routines, I'm assuming that the big 
> changes required will be in sim.giu.SimGraphics, sim.gui.DisplaySurface, 
> and the classes they touch. As such, before I get started, I'd like to 
> know if there is going to be any significant change to the display 
> system in 2.0 that I should take into account? Also, I'd like 
> suggestions as to which other classes I should be aware of.
> 
> Thanks,
> 
> Phil Feldman
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Repast-developer mailing list
> Rep...@li...
> https://lists.sourceforge.net/lists/listinfo/repast-developer
-- 
Tom Howe
Social Science Research Computing
University of Chicago

[Repast-developer] sim.gui.Display3D

[Phil F. <pfe...@co...>]

Hi All,

I'm looking at adding a 3D display surface to the RePast code I'm 
working on. I've done quite a bit of work with the Java3D api, and it 
seems reasonably speedy and stable.

Since J3D requires a Canvas3D, and anything drawn in the 3D space is not 
compatable with awt or swing drawing routines, I'm assuming that the big 
changes required will be in sim.giu.SimGraphics, sim.gui.DisplaySurface, 
and the classes they touch. As such, before I get started, I'd like to 
know if there is going to be any significant change to the display 
system in 2.0 that I should take into account? Also, I'd like 
suggestions as to which other classes I should be aware of.

Thanks,

Phil Feldman

[Repast-developer] Guess who's back?

[Laszlo G. <gu...@la...>]

... the spammer of the list!

That is to say, I loaded your respective mailboxes
with tons of rubbish and left. Only to have my in-box
overfilled soon after, as you may have noticed.

I apologize for this. Also, please let me know if I missed
something.

Thanks!

All the best,

gulya

Re: [Repast-developer] Topology Notes

[Laszlo G. <gu...@la...>]

Sorry, I forgot the attachment the last time.
(Not like you couldn't leave w/o it... ;-))

Take care!

Gulya

Re: [Repast-developer] Topology Notes

[Laszlo G. <gu...@la...>]

<html>
Hi Guys,<br><br>
I'm sorry for taking so long reacting, but there's so many things<br>
going on right now. (Not excluding selling the furniture and the=20
car<br>
in preparation to moving back to Europe.) So, my schedule was and<br>
is a bit hectic. Fortunately, though, both Anita (my wife) and I have
<br>
saved up some days off, so we're gonna take off for a last vacation=20
<br>
soon. Hopefully, I get back for the last couple of days much more <br>
relaxed/productive...<br><br>
However, I wanted to get back to you on this before that happens.<br>
I think, Mike has summarized our discussion rather well. The only<br>
thing remained to say is about displaying these things. In
principle,<br>
the Drawable interface works well: it basically maps an agent into<br>
a 2D coordinate system, plus provides a way for it to draw itself.<br>
This should be general enough.<br><br>
Except that it kind of makes it hard for an agent to participate in<br>
several [switchable] 'spaces' or to display itself on different displays
<br>
of the same [possibly N-dimensional] space. Now, I don't necessarily
<br>
think that it is time now [just before 2.0] to blow up the whole gui
package.<br>
However, I've been doing some experimentation and created my<br>
own ContextMapping (well, I call them contexts, but they are, kind<br>
of, generalized topologies) interface whose methods take an agent
and<br>
- map it into an (X,Y) /screen/ coordinate,<br>
- return its Dimension,<br>
- draw it on the screen.<br><br>
I just thought I'd share this with you. (See the attachment.) <br>
Please, do not look at its performance yet! On the other hand,<br>
it's kind of complex, so I won't blame you not want to start<br>
with it right now.<br><br>
- - - - - <br><br>
OK. In this model, I've taken the 'space/topology' issue a step <br>
further. (?) [Don't think I'm suggesting you should start implementing
<br>
any of this. Rather, I just want to share my crazy visions with
you.]<br><br>
Now I think that the bottom line of all these 'space/topology'<br>
issues is the concept of a Relation. It is really nothing else, but an
Edge <br>
on a network, so one nice thing about this approach is that it provides
<br>
a natural way to unify the 'grid-based' and the network models.<br><br>
OK, so I call them relations, not Edges, what's the difference?<br>
Technically, my implementation is nothing more than providing<br>
ways to sort out edges according to their types. This way, I have<br>
general methods to say, &quot;Give me the related nodes according to
<br>
relation R&quot;, R being a parameter.<br><br>
My 'contexts' create and update the relations and all the Model/Agent
<br>
do is to query and use them, via these general methods. This way, by
<br>
replacing the context, you can place the agents into vastly different
<br>
environments, as long as they all define the same relations.<br><br>
 From this point of view, the topologies/spaces just define special,
perhaps<br>
parametrized [with distance] 'neighborhood' or 'close-to' relations.
Storing<br>
the agents on a grid internally is just an efficient way of implementing
this.<br>
(Naturally, it is debatable whether the relations/edges define special
kinds<br>
of topologies, or the other way around, but this time, I just went with
the<br>
latter option.)<br><br>
Well, let me know what do you think. Note, however, that I'll be out
of<br>
town till December 3. So, don't get mad at me if I won't answer=20
them<br>
immediately. (Well, that's kind of usual from me, sadly=20
enough.)<br><br>
Take care!<br><br>
Gulya<br><br>
PS: I can't resist to put this in here: as a long shot off the 'relation
burble':<br>
this could, in fact, finally lead to the 'DB-based' simulation I've
been<br>
'visioning' for a while. I mean, if relations are a central concept in
the<br>
architecture, and the model's and the agents' logic is formulated
according<br>
to this, it could be possible to actually implement them by storing
them<br>
in a relational DB. Then, in principle, one could do cool stuff, like
<br>
defining 'dynamic relationships' via joints, or creating triggers,
etc.<br>
I'm not sure if it's necessarily more efficient, but wouldn't it be
cool?! ;-) <br>
[Enough of me now! :-)]<br><br>
At 07:15 PM 11/15/2002 -0600, North, Michael wrote:<br><br>
<blockquote type=3Dcite class=3Dcite cite><font face=3D"Times New Roman,=
 Times">Tom:<br>
</font><br>
<font face=3D"Times New Roman, Times">&nbsp;<br>
</font><br>
<font face=3D"Times New Roman, Times">The topology issues that we discussed
might be represented as follows:<br>
</font><br>
<font face=3D"Times New Roman, Times">&nbsp;<br>
</font><br>
<font face=3D"Times New Roman, Times">1.)</font><font face=3D"Times New=
 Roman, Times" size=3D1>&nbsp;&nbsp;&nbsp;
</font>An abstract Topology class or interface can be defined:<br><br>
<font face=3D"Times New Roman, Times">a.</font><font face=3D"Times New=
 Roman, Times" size=3D1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</font>The class has a method, getDistance(Object o1, Object o2), that
returns the distance between any two objects.<br><br>
<font face=3D"Times New Roman, Times">b.</font><font face=3D"Times New=
 Roman, Times" size=3D1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</font>The Topology class has appropriate methods to get neighbors within
a certain range such as getNeighbors(Object o1, double range) .<br><br>
<font face=3D"Times New Roman, Times">2.)</font><font face=3D"Times New=
 Roman, Times" size=3D1>&nbsp;&nbsp;&nbsp;
</font>Three or more concrete Topology implementation classes can then be
defined:<br><br>
<font face=3D"Times New Roman, Times">a.</font><font face=3D"Times New=
 Roman, Times" size=3D1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</font>An implementation for Moore neighborhoods, von Neumann
neighborhoods, and hexagonal neighborhoods based on the current grid
implementation can be defined.&nbsp; This would use the current
array-based grid storage and maintain backward compatibility.&nbsp; Since
it is essentially the current implementation, it would run as fast as the
current code.<br><br>
<font face=3D"Times New Roman, Times">b.</font><font face=3D"Times New=
 Roman, Times" size=3D1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</font>An implementation for metric spaces can be defined that uses trees
to store objects and find neighbors.&nbsp; This can be done since the
rules of a metric space allow tree storage.&nbsp; For example see
<a href=3D"http://www.vldb.org/conf/1997/P426.PDF">http://www.vldb.org/conf/=
1997/P426.PDF</a>.&nbsp;
Other implementations are also available, especially for large
lists.&nbsp; For example, see
<a href=3D"http://portal.acm.org/citation.cfm?id=3D328959&amp;dl=3DACM&amp;c=
oll=3Dportal">http://portal.acm.org/citation.cfm?id=3D328959&amp;dl=3DACM&am=
p;coll=3Dportal</a>.&nbsp;
This implementation would run slower than the current code but it would
still be reasonable for most problems.&nbsp; The price of slower
execution is made up for by the added flexibility.<br><br>
<font face=3D"Times New Roman, Times">c.</font><font face=3D"Times New=
 Roman, Times" size=3D1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</font>An implementation for completely abstract (i.e. non-metric) spaces
can be defined that uses a simple list to store objects and a na=EFve all
pairs matching algorithm to find neighbors.&nbsp; The algorithm will
simply test the distance between each object to find neighbors.&nbsp;
This implementation will be much slower than the current code for large
lists but the slower execution will be made up for by the increased
flexibility, at least for initial testing.&nbsp; Users that find they
need a particularly abstract notion of space are free to develop
optimized versions of the Topology class as they see fit.<br><br>
<font face=3D"Times New Roman, Times">3.)</font><font face=3D"Times New=
 Roman, Times" size=3D1>&nbsp;&nbsp;&nbsp;
</font>Users select the fastest concrete implementation class that
supports their model's notion of space.&nbsp; Of course, users are also
free to extend or add to the existing concrete classes.<br><br>
<font face=3D"Times New Roman, Times">&nbsp;<br>
</font><br>
<font face=3D"Times New Roman, Times">Mike<br>
</font><br>
<font face=3D"Times New Roman, Times">&nbsp;<br>
</font><br>
<font face=3D"Times New Roman, Times">&nbsp;</font></blockquote></html>

[Repast-developer] Topology Notes

[North, M. <no...@an...>]

Tom:
=20
The topology issues that we discussed might be represented as follows:
=20
1.)    An abstract Topology class or interface can be defined:
a.       The class has a method, getDistance(Object o1, Object o2), =
that
returns the distance between any two objects.
b.      The Topology class has appropriate methods to get neighbors =
within a
certain range such as getNeighbors(Object o1, double range) .
2.)    Three or more concrete Topology implementation classes can then =
be
defined:
a.       An implementation for Moore neighborhoods, von Neumann
neighborhoods, and hexagonal neighborhoods based on the current grid
implementation can be defined.  This would use the current array-based =
grid
storage and maintain backward compatibility.  Since it is essentially =
the
current implementation, it would run as fast as the current code.
b.      An implementation for metric spaces can be defined that uses =
trees
to store objects and find neighbors.  This can be done since the rules =
of a
metric space allow tree storage.  For example see
http://www.vldb.org/conf/1997/P426.PDF
<http://www.vldb.org/conf/1997/P426.PDF> .  Other implementations are =
also
available, especially for large lists.  For example, see
http://portal.acm.org/citation.cfm?id=3D328959
<http://portal.acm.org/citation.cfm?id=3D328959&dl=3DACM&coll=3Dportal>
&dl=3DACM&coll=3Dportal.  This implementation would run slower than the =
current
code but it would still be reasonable for most problems.  The price of
slower execution is made up for by the added flexibility.
c.       An implementation for completely abstract (i.e. non-metric) =
spaces
can be defined that uses a simple list to store objects and a na=EFve =
all
pairs matching algorithm to find neighbors.  The algorithm will simply =
test
the distance between each object to find neighbors.  This =
implementation
will be much slower than the current code for large lists but the =
slower
execution will be made up for by the increased flexibility, at least =
for
initial testing.  Users that find they need a particularly abstract =
notion
of space are free to develop optimized versions of the Topology class =
as
they see fit.
3.)    Users select the fastest concrete implementation class that =
supports
their model's notion of space.  Of course, users are also free to =
extend or
add to the existing concrete classes.
=20
Mike
=20
=20

Re: [Repast-developer] custom charts question + properties

[Nick C. <nic...@ve...>]

Hi,

On public data fields: Certainly public fields will work fine w/r to
dynamically compiled classes. I'm just don't see them very often :).

non-model classes: good solution. As you say its certainly possible to
get the fully qualified names of all available classes. I was too
fixated on getting those _only_ in the user's package and missed this.

Anyway, thanks for the prototype. I'll take a look at it this morning.
By the way, this should be the last addition for repast 2.0 on my side.
We really need to get it out the door. Especially before we get swamped
by model development again.

Nick


On Tue, 2002-11-12 at 23:05, Laszlo Gulyas wrote:
> Hi,
> 
> And now, after all that coding, let me get back to these.
> Probably, I should have done this first... ;-)
> 
> At 11:34 AM 11/12/2002 -0500, Nick Collier wrote:
> >Hi,
> >
> >I've given this a bit more thought, and I have some concerns.
> >
> >Public Methods in the model class:
> >
> >Introspect the model and get a list of all the methods that return
> >either a primitive number or an instance of Number. These methods can be
> 
> Maybe I am completely out of scope here, but why should we always have
> a _method_ returning the value? I mean, public data fields should also be
> accessible... (I don't know about the byte code-generator, but values can
> be lured out of them via introspection for sure.) In fact, I wonder if the
> methods are really necessary in probing, too?


> On the other hand, recognizing subclasses of Number is a good point.
> This is missing from my UI-prototype.
> 
> >wrapped by dynamically compiled Sequences and thus displayed and updated
> >appropriately in the graph. Assuming the methods are public, there is no
> >reflection here other than when the list of appropriate methods is first
> >created. So far, no problem.
> 
> OK. I believe this to be true for the data fields, too. But again, my knowledge
> is limited.
> 
> >Private/Protected Fields and methods in the model class are more
> >problematic:
> >
> >As above we use reflection to create a list of numeric fields / methods.
> >However, the Sequences that provide the value of these fields / methods
> >to the OpenSequenceGraph for display and recording will use reflection
> >every time the graph is updated. This can be quite slow. The problem
> >here is that there is no way for a dynamically compiled Sequence to have
> >access to private / protected methods / fields unless that Sequence is
> >either an inner class of the model class or uses reflection on the
> >model. In this latter case, the Sequence would not need to be
> >dynamically compiled anyway. Note that the point of the dynamic creation
> >and compilation of a Sequence is intended to remove the necessity for
> >reflection. It may be possible to make the Sequences inner classes of
> >the model on the fly, but I'm not optimistic.
> 
> OK, it may be hard to generate inner classes on the fly... Therefore,
> considering the rush for 2.0, I think, we shouldn't count on that.
> 
> I think, we either have to leave the private/protected fields out of the 
> game for
> now, or provide them using reflection, with the warning that it could be a big
> performance hit.
> 
> On one hand, this would be a powerful option, but on the other, I can foresee
> it popping up continuously on the mailing list. Therefore, if the option 
> will be
> included, the warning should be really explicit and 'visible'. I could even 
> imagine
> this as an advanced option ('behind' a UI switch).  Or, perhaps, it should 
> always
> be there, but a warning window should come up each time when used? :-)
> 
> In the long run [in some later versions] we might get back to the inner class
> option, though.
> 
> 
> >Using Non-model classes:
> >
> >This is hard because repast doesn't know anything about these classes.
> >All it knows about is the model. Furthermore, it doesn't look like its
> >possible to retrieve all the Class objects in a particular package
> >before those classes have been loaded. And even then I think a custom
> >ClassLoader is necessary. So, that leaves it up to the user to input the
> 
> Well, if I understand what you mean, my prototype should be a good
> argument that it is possible. There, I am iterating through the files that
> are accessible via the value of the "java.class.path" system property.
> True, the selected classes should be loaded, but that's not that big a
> deal, I think. Once the appropriate class is selected, it shouldn't be
> hard to generate code that attempts to cast the objects in the collection
> to the selected type. (Again, if I am not much mistaken...)
> 
> Note, that according to what I have in mind, these 'outside' classes are
> only needed if the user picked a collection. Then, it is used to cast the
> members of the collection. Otherwise, the user can only select variables
> that are 'accessible' (could be referenced) from the Model object.
> 
> I am not sure how much sense I am making. I hope the prototype helps
> me explaining it... ;-)
> 
> >name of the non-model class. For example, the user would choose the
> >"agent list" from a list of fields in the model and provide the class
> >name of the agents contained in the list. A list of methods in the agent
> >class could then be produced. Alternatively, the user could just specify
> >the method itself, but it would be hard to check if this method was
> >valid without knowing the class it belongs to. Also working with agent
> >list field requires using reflection as mentioned above. At some point,
> >it seems as if might be simpler for the user to create the graph in code
> >as is required now.
> >
> >If we add something like agentIterator() to SimModel, or some other
> >interface that is required for this kind of graph building that would at
> >least remove the agentList reflection problem. My other concerns could
> >probably be eliminated as well through new Interfaces, superclasses etc.
> 
> I think we don't really need an agentIterator() for this, but this all seem
> to be tied to the fact that I assume that public variables can be accessed
> from the generated code. (SimpleModel's agentList is protected at this
> point, which, of course, makes things harder...)
> 
> Cheers,
> 
> Gulya
> 
-- 
Nick Collier 
Social Science Research Computing 
University of Chicago 
http://repast.sourceforge.net

Re: [Repast-developer] custom charts question + properties

[Laszlo G. <gu...@la...>]

Hi,

At 11:49 AM 11/12/2002 -0500, Nick Collier wrote:
>On Tue, 2002-11-12 at 11:47, Thomas R. Howe wrote:
> > My feeling is that agentIterator is a very good idea.  First it cleans
> > up some of the work with the agent list.  Makes it feel a bit more like
> > the agents are really part of the model.  I've always felt like it was a
> > little weird that there was no real mention of the agents in the model
> > definition.  I'm trying to come up with a situation where this would be
> > a problem, I haven't yet, but we'll see :). Adding a stock
> > implementation of agentIterator wouldn't be much of a problem either.

 From a broader perspective, I can imagine the agentIterator() to be really
useful. However, I must be careful here as I might see too much 'into'
the proposal. I mean, if it's only a hasMoreAgents(), getNextAgent(),
getAgentIterator() triplet, then I am not sure if it's worth the effort.
You'd still need to organize loops around it and it's not much easier than
via Iterator i = agentList.iterator();.

However, if it's a way to have 'vectorized' operations (executed on all
agents), then I am pretty much for it. I know, however, that this raises a
number of problems and work, so don't take it as another crazy 'request'
from me...! :-)


> > Seems like having the extra interfaces (not unlike the customProbeable
> > interface, I presume), would solve the problems you discuss, but I kind
> > of wonder if we have gained anything at that point.  The user still has
> > to think through in advance what he wants to chart, although, he doesn't
> > need to write the Sequences which is nice. Maybe I'm not thinking of the
> > same kinds of interfaces that you are.
>
>I agree. I'm not seeing what we've gained. But this maybe because I'm
>not thinking through the Interfaces correctly.

OK, guys. I'll wait for you to comment on my previous ranting. You both
really sound as it was hard/impossible to access data members for some
reason. So, it must be true...

Take care!

Gulya

Re: [Repast-developer] custom charts question + properties

[Laszlo G. <gu...@la...>]

Hi,

And now, after all that coding, let me get back to these.
Probably, I should have done this first... ;-)

At 11:34 AM 11/12/2002 -0500, Nick Collier wrote:
>Hi,
>
>I've given this a bit more thought, and I have some concerns.
>
>Public Methods in the model class:
>
>Introspect the model and get a list of all the methods that return
>either a primitive number or an instance of Number. These methods can be

Maybe I am completely out of scope here, but why should we always have
a _method_ returning the value? I mean, public data fields should also be
accessible... (I don't know about the byte code-generator, but values can
be lured out of them via introspection for sure.) In fact, I wonder if the
methods are really necessary in probing, too?

On the other hand, recognizing subclasses of Number is a good point.
This is missing from my UI-prototype.

>wrapped by dynamically compiled Sequences and thus displayed and updated
>appropriately in the graph. Assuming the methods are public, there is no
>reflection here other than when the list of appropriate methods is first
>created. So far, no problem.

OK. I believe this to be true for the data fields, too. But again, my knowledge
is limited.

>Private/Protected Fields and methods in the model class are more
>problematic:
>
>As above we use reflection to create a list of numeric fields / methods.
>However, the Sequences that provide the value of these fields / methods
>to the OpenSequenceGraph for display and recording will use reflection
>every time the graph is updated. This can be quite slow. The problem
>here is that there is no way for a dynamically compiled Sequence to have
>access to private / protected methods / fields unless that Sequence is
>either an inner class of the model class or uses reflection on the
>model. In this latter case, the Sequence would not need to be
>dynamically compiled anyway. Note that the point of the dynamic creation
>and compilation of a Sequence is intended to remove the necessity for
>reflection. It may be possible to make the Sequences inner classes of
>the model on the fly, but I'm not optimistic.

OK, it may be hard to generate inner classes on the fly... Therefore,
considering the rush for 2.0, I think, we shouldn't count on that.

I think, we either have to leave the private/protected fields out of the 
game for
now, or provide them using reflection, with the warning that it could be a big
performance hit.

On one hand, this would be a powerful option, but on the other, I can foresee
it popping up continuously on the mailing list. Therefore, if the option 
will be
included, the warning should be really explicit and 'visible'. I could even 
imagine
this as an advanced option ('behind' a UI switch).  Or, perhaps, it should 
always
be there, but a warning window should come up each time when used? :-)

In the long run [in some later versions] we might get back to the inner class
option, though.


>Using Non-model classes:
>
>This is hard because repast doesn't know anything about these classes.
>All it knows about is the model. Furthermore, it doesn't look like its
>possible to retrieve all the Class objects in a particular package
>before those classes have been loaded. And even then I think a custom
>ClassLoader is necessary. So, that leaves it up to the user to input the

Well, if I understand what you mean, my prototype should be a good
argument that it is possible. There, I am iterating through the files that
are accessible via the value of the "java.class.path" system property.
True, the selected classes should be loaded, but that's not that big a
deal, I think. Once the appropriate class is selected, it shouldn't be
hard to generate code that attempts to cast the objects in the collection
to the selected type. (Again, if I am not much mistaken...)

Note, that according to what I have in mind, these 'outside' classes are
only needed if the user picked a collection. Then, it is used to cast the
members of the collection. Otherwise, the user can only select variables
that are 'accessible' (could be referenced) from the Model object.

I am not sure how much sense I am making. I hope the prototype helps
me explaining it... ;-)

>name of the non-model class. For example, the user would choose the
>"agent list" from a list of fields in the model and provide the class
>name of the agents contained in the list. A list of methods in the agent
>class could then be produced. Alternatively, the user could just specify
>the method itself, but it would be hard to check if this method was
>valid without knowing the class it belongs to. Also working with agent
>list field requires using reflection as mentioned above. At some point,
>it seems as if might be simpler for the user to create the graph in code
>as is required now.
>
>If we add something like agentIterator() to SimModel, or some other
>interface that is required for this kind of graph building that would at
>least remove the agentList reflection problem. My other concerns could
>probably be eliminated as well through new Interfaces, superclasses etc.

I think we don't really need an agentIterator() for this, but this all seem
to be tied to the fact that I assume that public variables can be accessed
from the generated code. (SimpleModel's agentList is protected at this
point, which, of course, makes things harder...)

Cheers,

Gulya

[Repast-developer] chartbuilder prototype

[Laszlo G. <gu...@la...>]

Hi,

OK, here it is. Please, find the prototype I was talking about attached.
It's really just the GUI part, so perhaps, there are serious pitfalls that
I didn't realize in generating code from these. My rule of thumb was that
since I can always lure a value out of these selections (via introspection
or otherwise) it should always be possible to generate code from it.
Maybe, I am mistaken, however...

As for how it works: the Tester launches all the 'flashy' stuff. The Model.java
is only there for testing purposes. The usage is intended to be 
self-explanatory,
but we'll see... :-)

Also, please note that it is really just a prototype. It is incomplete and
there are known bugs in it. Including:

- Aesthetic issues: I'm really poor at Swing.
- No actual code is generated.
- No persistence: i.e., no save or load.
- The parameters aren't working on the Charts and on the Sources.
- Cancel doesn't work at a number of places.
- Several efficiency issues: not optimized at all!
- The code is rather messy.
- Etc.


Well, let me know what do you think!

Take care!

Gulya

Re: [Repast-developer] custom charts question + properties

[Laszlo G. <gu...@la...>]

Hi,

I'll comment on this in some more detail soon. Currently, I am
in somewhat of a hurry. Anyhow, I've also been thinking, or rather,
experimenting. I've started to put together a prototype version of
the builder (except for actually generating the dynamic chart) to
show you how I think it should work. I'm almost ready with it and
I'll mail it to you soon.

In short, I am not worried too much about private/protected methods.
If we can do something about them, fine, but otherwise, I would think
that can be required of the users. Even if this would lead to making
all of their fields public. (My students do it that way, anyway, as
they only had a crash-course on Java, so we didn't bother with
visibility...)

As for the non-model classes: you have a point there, but the
situation is better than you describe, I think. In my prototype,
you start out browsing (via a JTree) from the Model (or from any
class now). If you pick a field with double/float/.../etc., then
you're fine. So you are, if you pick a method that returns such
a value and takes no parameters. If you pick a field that has an
object for a value (of a method that returns such a thing) then
it 'opens up', showing the internals and you go on as above.

However, you can also pick an array or a collection object.
If it's an array, we are in pretty good shape: the type can
be determined. On the other hand, if it's a collection, you are
also required to pick another, the 'element' source. Here you
need to pick a class/interface first and then, everything goes
as in the browsing panel above, except that you cannot pick an
array/collection anymore.

Now, the tricky part is picking a class/interface. The simplest
solution is to require the user to type in the name, but I'm currently
working on to provide a browser for this, too. In principle, this should
be possible as JBuilder and all the IDE's have boxes like this. Well,
more on that later.

I know, this scheme is not perfect, but (at this point? :-)) I'd be
perfectly happy with it.

So, this mail got rather longer than I expected... I'll send the prototype
off soon. Keep your expectations low, however, as I am a rather poor
Swing programmer...

Cheers,

Gulya

At 11:34 AM 11/12/2002 -0500, Nick Collier wrote:
>Hi,
>
>I've given this a bit more thought, and I have some concerns.
>
>Public Methods in the model class:
>
>Introspect the model and get a list of all the methods that return
>either a primitive number or an instance of Number. These methods can be
>wrapped by dynamically compiled Sequences and thus displayed and updated
>appropriately in the graph. Assuming the methods are public, there is no
>reflection here other than when the list of appropriate methods is first
>created. So far, no problem.
>
>Private/Protected Fields and methods in the model class are more
>problematic:
>
>As above we use reflection to create a list of numeric fields / methods.
>However, the Sequences that provide the value of these fields / methods
>to the OpenSequenceGraph for display and recording will use reflection
>every time the graph is updated. This can be quite slow. The problem
>here is that there is no way for a dynamically compiled Sequence to have
>access to private / protected methods / fields unless that Sequence is
>either an inner class of the model class or uses reflection on the
>model. In this latter case, the Sequence would not need to be
>dynamically compiled anyway. Note that the point of the dynamic creation
>and compilation of a Sequence is intended to remove the necessity for
>reflection. It may be possible to make the Sequences inner classes of
>the model on the fly, but I'm not optimistic.
>
>Using Non-model classes:
>
>This is hard because repast doesn't know anything about these classes.
>All it knows about is the model. Furthermore, it doesn't look like its
>possible to retrieve all the Class objects in a particular package
>before those classes have been loaded. And even then I think a custom
>ClassLoader is necessary. So, that leaves it up to the user to input the
>name of the non-model class. For example, the user would choose the
>"agent list" from a list of fields in the model and provide the class
>name of the agents contained in the list. A list of methods in the agent
>class could then be produced. Alternatively, the user could just specify
>the method itself, but it would be hard to check if this method was
>valid without knowing the class it belongs to. Also working with agent
>list field requires using reflection as mentioned above. At some point,
>it seems as if might be simpler for the user to create the graph in code
>as is required now.
>
>If we add something like agentIterator() to SimModel, or some other
>interface that is required for this kind of graph building that would at
>least remove the agentList reflection problem. My other concerns could
>probably be eliminated as well through new Interfaces, superclasses etc.
>
>Comments?
>
>Nick
>
>On Thu, 2002-11-07 at 16:16, Laszlo Gulyas wrote:
> > Hi,
> >
> > Thanks Nick, this sounds awesome! Please find my comments below.
> >
> > Gulya
> >
> > At 09:11 AM 11/7/2002 -0500, Nick Collier wrote:
> > >Hi,
> > >
> > >I've added support of the dynamic compilation of sequences and histogram
> > >items for the various kinds of charts in repast. I've also fiddled with
> > >the internals a bit so they should be a bit faster and look a bit
> > >better.
> > >
> > >All this should make it fairly easy to create a chart building GUI so
> > >the user can add charts on the fly. Data is received by a chart via some
> > >class that implements Sequence. This is essentially a single method
> > >class whose method returns a double. Thus, for chart building I'm
> > >thinking of introspecting the model and returning all the methods that
> > >return a number. These can be wrapped in a dynamically compiled
> > >sequence. Something similar could be done for histograms.
> > >
> > >However, this approach sort of bothers me in that it assumes the methods
> > >of interest are already defined. Maybe we also need to iterate over all
> > >the agents calling some method on each one and then plot the average,
> > >for example. I don't want to do too much here as Tom and I are keen to
> > >get 2.0 out the door as its been a bit delayed as he and I have been
> > >writing models. So, any comments?
> >
> > Disclaimer: I have very limited experience with introspection, so I
> > apologize if what I say is nonsense. [Although, in the last 30 mins
> > I've made some experiments, so it seems this may be doable.]
> >
> > That said, what I originally had in mind was something like this:
> >
> > a)
> > A menu with all the classes in the model's (?) package, you
> > could pick a class from it. (By default, it would be the model.)
> > Then, a menu of all the methods returning a value, PLUS all
> > the data members having a double/float/int/long/etc. type
> > would show up. You'd pick the data source from it.
> >
> > b)
> > Alternatively, in the second step, the menu could show all
> > the collections (or perhaps, all arrays, too) available to
> > extract data from them [and calculate min/max/avg/sum].
> > It's much trickier, though, as with collections, you don't know
> > what kind of objects you are facing. So, perhaps, we should,
> > indeed, scale back to the agents... On the other hand,
> > we could force the user to pick a class/interface and throw
> > away all objects in the generated code that don't adhere...
> > (Although, I'm afraid this would get way too complicated for
> > the users...)
> >
> > >Also, Gulya had a good suggestion about remembering the position and
> > >sizes of windows and so forth. If this is to be done between runs, but
> > >not between application instances then no problem. If we want to do it
> > >between application instances, and I think we do, then we'll need to use
> > >a file format to store this info. Java 1.4's new property mechanism
> > >would be good for this, but 1.4 is not really available for the Mac yet.
> > >So, I'm thinking a simple XML format. I'd go with java's properties
> > >format, but I think we'd might grow out of that at some time. We could
> >
> > I haven't got much experience with java properties, so I don't know.
> > In principle, XML sounds good to me.
> >
> > Take care! Gulya
> >
>--
>Nick Collier
>Social Science Research Computing
>University of Chicago
>http://repast.sourceforge.net

Re: [Repast-developer] custom charts question + properties

[Nick C. <nic...@ve...>]

On Tue, 2002-11-12 at 11:47, Thomas R. Howe wrote:
> My feeling is that agentIterator is a very good idea.  First it cleans
> up some of the work with the agent list.  Makes it feel a bit more like
> the agents are really part of the model.  I've always felt like it was a
> little weird that there was no real mention of the agents in the model
> definition.  I'm trying to come up with a situation where this would be
> a problem, I haven't yet, but we'll see :). Adding a stock
> implementation of agentIterator wouldn't be much of a problem either.
> 
> Seems like having the extra interfaces (not unlike the customProbeable
> interface, I presume), would solve the problems you discuss, but I kind
> of wonder if we have gained anything at that point.  The user still has
> to think through in advance what he wants to chart, although, he doesn't
> need to write the Sequences which is nice. Maybe I'm not thinking of the
> same kinds of interfaces that you are.

I agree. I'm not seeing what we've gained. But this maybe because I'm
not thinking through the Interfaces correctly.

> Anyhoo, that's my two cents for the moment.
> 
> -Tom
> 
> 
> On Tue, 2002-11-12 at 10:34, Nick Collier wrote:
> > Hi,
> > 
> > I've given this a bit more thought, and I have some concerns.
> > 
> > Public Methods in the model class:
> > 
> > Introspect the model and get a list of all the methods that return
> > either a primitive number or an instance of Number. These methods can be
> > wrapped by dynamically compiled Sequences and thus displayed and updated
> > appropriately in the graph. Assuming the methods are public, there is no
> > reflection here other than when the list of appropriate methods is first
> > created. So far, no problem.
> > 
> > Private/Protected Fields and methods in the model class are more
> > problematic:
> > 
> > As above we use reflection to create a list of numeric fields / methods.
> > However, the Sequences that provide the value of these fields / methods
> > to the OpenSequenceGraph for display and recording will use reflection
> > every time the graph is updated. This can be quite slow. The problem
> > here is that there is no way for a dynamically compiled Sequence to have
> > access to private / protected methods / fields unless that Sequence is
> > either an inner class of the model class or uses reflection on the
> > model. In this latter case, the Sequence would not need to be
> > dynamically compiled anyway. Note that the point of the dynamic creation
> > and compilation of a Sequence is intended to remove the necessity for
> > reflection. It may be possible to make the Sequences inner classes of
> > the model on the fly, but I'm not optimistic.
> > 
> > Using Non-model classes:
> > 
> > This is hard because repast doesn't know anything about these classes.
> > All it knows about is the model. Furthermore, it doesn't look like its
> > possible to retrieve all the Class objects in a particular package
> > before those classes have been loaded. And even then I think a custom
> > ClassLoader is necessary. So, that leaves it up to the user to input the
> > name of the non-model class. For example, the user would choose the
> > "agent list" from a list of fields in the model and provide the class
> > name of the agents contained in the list. A list of methods in the agent
> > class could then be produced. Alternatively, the user could just specify
> > the method itself, but it would be hard to check if this method was
> > valid without knowing the class it belongs to. Also working with agent
> > list field requires using reflection as mentioned above. At some point,
> > it seems as if might be simpler for the user to create the graph in code
> > as is required now.
> > 
> > If we add something like agentIterator() to SimModel, or some other
> > interface that is required for this kind of graph building that would at
> > least remove the agentList reflection problem. My other concerns could
> > probably be eliminated as well through new Interfaces, superclasses etc.
> > 
> > Comments?
> > 
> > Nick
> > 
> > On Thu, 2002-11-07 at 16:16, Laszlo Gulyas wrote:
> > > Hi,
> > > 
> > > Thanks Nick, this sounds awesome! Please find my comments below.
> > > 
> > > Gulya
> > > 
> > > At 09:11 AM 11/7/2002 -0500, Nick Collier wrote:
> > > >Hi,
> > > >
> > > >I've added support of the dynamic compilation of sequences and histogram
> > > >items for the various kinds of charts in repast. I've also fiddled with
> > > >the internals a bit so they should be a bit faster and look a bit
> > > >better.
> > > >
> > > >All this should make it fairly easy to create a chart building GUI so
> > > >the user can add charts on the fly. Data is received by a chart via some
> > > >class that implements Sequence. This is essentially a single method
> > > >class whose method returns a double. Thus, for chart building I'm
> > > >thinking of introspecting the model and returning all the methods that
> > > >return a number. These can be wrapped in a dynamically compiled
> > > >sequence. Something similar could be done for histograms.
> > > >
> > > >However, this approach sort of bothers me in that it assumes the methods
> > > >of interest are already defined. Maybe we also need to iterate over all
> > > >the agents calling some method on each one and then plot the average,
> > > >for example. I don't want to do too much here as Tom and I are keen to
> > > >get 2.0 out the door as its been a bit delayed as he and I have been
> > > >writing models. So, any comments?
> > > 
> > > Disclaimer: I have very limited experience with introspection, so I
> > > apologize if what I say is nonsense. [Although, in the last 30 mins
> > > I've made some experiments, so it seems this may be doable.]
> > > 
> > > That said, what I originally had in mind was something like this:
> > > 
> > > a)
> > > A menu with all the classes in the model's (?) package, you
> > > could pick a class from it. (By default, it would be the model.)
> > > Then, a menu of all the methods returning a value, PLUS all
> > > the data members having a double/float/int/long/etc. type
> > > would show up. You'd pick the data source from it.
> > > 
> > > b)
> > > Alternatively, in the second step, the menu could show all
> > > the collections (or perhaps, all arrays, too) available to
> > > extract data from them [and calculate min/max/avg/sum].
> > > It's much trickier, though, as with collections, you don't know
> > > what kind of objects you are facing. So, perhaps, we should,
> > > indeed, scale back to the agents... On the other hand,
> > > we could force the user to pick a class/interface and throw
> > > away all objects in the generated code that don't adhere...
> > > (Although, I'm afraid this would get way too complicated for
> > > the users...)
> > > 
> > > >Also, Gulya had a good suggestion about remembering the position and
> > > >sizes of windows and so forth. If this is to be done between runs, but
> > > >not between application instances then no problem. If we want to do it
> > > >between application instances, and I think we do, then we'll need to use
> > > >a file format to store this info. Java 1.4's new property mechanism
> > > >would be good for this, but 1.4 is not really available for the Mac yet.
> > > >So, I'm thinking a simple XML format. I'd go with java's properties
> > > >format, but I think we'd might grow out of that at some time. We could
> > > 
> > > I haven't got much experience with java properties, so I don't know.
> > > In principle, XML sounds good to me.
> > > 
> > > Take care! Gulya
> > > 
> -- 
> Thomas R. Howe <th...@st...>
> 
-- 
Nick Collier 
Social Science Research Computing 
University of Chicago 
http://repast.sourceforge.net

Re: [Repast-developer] custom charts question + properties

[Nick C. <nic...@ve...>]

Hi,

I've given this a bit more thought, and I have some concerns.

Public Methods in the model class:

Introspect the model and get a list of all the methods that return
either a primitive number or an instance of Number. These methods can be
wrapped by dynamically compiled Sequences and thus displayed and updated
appropriately in the graph. Assuming the methods are public, there is no
reflection here other than when the list of appropriate methods is first
created. So far, no problem.

Private/Protected Fields and methods in the model class are more
problematic:

As above we use reflection to create a list of numeric fields / methods.
However, the Sequences that provide the value of these fields / methods
to the OpenSequenceGraph for display and recording will use reflection
every time the graph is updated. This can be quite slow. The problem
here is that there is no way for a dynamically compiled Sequence to have
access to private / protected methods / fields unless that Sequence is
either an inner class of the model class or uses reflection on the
model. In this latter case, the Sequence would not need to be
dynamically compiled anyway. Note that the point of the dynamic creation
and compilation of a Sequence is intended to remove the necessity for
reflection. It may be possible to make the Sequences inner classes of
the model on the fly, but I'm not optimistic.

Using Non-model classes:

This is hard because repast doesn't know anything about these classes.
All it knows about is the model. Furthermore, it doesn't look like its
possible to retrieve all the Class objects in a particular package
before those classes have been loaded. And even then I think a custom
ClassLoader is necessary. So, that leaves it up to the user to input the
name of the non-model class. For example, the user would choose the
"agent list" from a list of fields in the model and provide the class
name of the agents contained in the list. A list of methods in the agent
class could then be produced. Alternatively, the user could just specify
the method itself, but it would be hard to check if this method was
valid without knowing the class it belongs to. Also working with agent
list field requires using reflection as mentioned above. At some point,
it seems as if might be simpler for the user to create the graph in code
as is required now.

If we add something like agentIterator() to SimModel, or some other
interface that is required for this kind of graph building that would at
least remove the agentList reflection problem. My other concerns could
probably be eliminated as well through new Interfaces, superclasses etc.

Comments?

Nick

On Thu, 2002-11-07 at 16:16, Laszlo Gulyas wrote:
> Hi,
> 
> Thanks Nick, this sounds awesome! Please find my comments below.
> 
> Gulya
> 
> At 09:11 AM 11/7/2002 -0500, Nick Collier wrote:
> >Hi,
> >
> >I've added support of the dynamic compilation of sequences and histogram
> >items for the various kinds of charts in repast. I've also fiddled with
> >the internals a bit so they should be a bit faster and look a bit
> >better.
> >
> >All this should make it fairly easy to create a chart building GUI so
> >the user can add charts on the fly. Data is received by a chart via some
> >class that implements Sequence. This is essentially a single method
> >class whose method returns a double. Thus, for chart building I'm
> >thinking of introspecting the model and returning all the methods that
> >return a number. These can be wrapped in a dynamically compiled
> >sequence. Something similar could be done for histograms.
> >
> >However, this approach sort of bothers me in that it assumes the methods
> >of interest are already defined. Maybe we also need to iterate over all
> >the agents calling some method on each one and then plot the average,
> >for example. I don't want to do too much here as Tom and I are keen to
> >get 2.0 out the door as its been a bit delayed as he and I have been
> >writing models. So, any comments?
> 
> Disclaimer: I have very limited experience with introspection, so I
> apologize if what I say is nonsense. [Although, in the last 30 mins
> I've made some experiments, so it seems this may be doable.]
> 
> That said, what I originally had in mind was something like this:
> 
> a)
> A menu with all the classes in the model's (?) package, you
> could pick a class from it. (By default, it would be the model.)
> Then, a menu of all the methods returning a value, PLUS all
> the data members having a double/float/int/long/etc. type
> would show up. You'd pick the data source from it.
> 
> b)
> Alternatively, in the second step, the menu could show all
> the collections (or perhaps, all arrays, too) available to
> extract data from them [and calculate min/max/avg/sum].
> It's much trickier, though, as with collections, you don't know
> what kind of objects you are facing. So, perhaps, we should,
> indeed, scale back to the agents... On the other hand,
> we could force the user to pick a class/interface and throw
> away all objects in the generated code that don't adhere...
> (Although, I'm afraid this would get way too complicated for
> the users...)
> 
> >Also, Gulya had a good suggestion about remembering the position and
> >sizes of windows and so forth. If this is to be done between runs, but
> >not between application instances then no problem. If we want to do it
> >between application instances, and I think we do, then we'll need to use
> >a file format to store this info. Java 1.4's new property mechanism
> >would be good for this, but 1.4 is not really available for the Mac yet.
> >So, I'm thinking a simple XML format. I'd go with java's properties
> >format, but I think we'd might grow out of that at some time. We could
> 
> I haven't got much experience with java properties, so I don't know.
> In principle, XML sounds good to me.
> 
> Take care! Gulya
> 
-- 
Nick Collier 
Social Science Research Computing 
University of Chicago 
http://repast.sourceforge.net

Re: [Repast-developer] custom charts question + properties

[Laszlo G. <gu...@la...>]

Hi,

Thanks Nick, this sounds awesome! Please find my comments below.

Gulya

At 09:11 AM 11/7/2002 -0500, Nick Collier wrote:
>Hi,
>
>I've added support of the dynamic compilation of sequences and histogram
>items for the various kinds of charts in repast. I've also fiddled with
>the internals a bit so they should be a bit faster and look a bit
>better.
>
>All this should make it fairly easy to create a chart building GUI so
>the user can add charts on the fly. Data is received by a chart via some
>class that implements Sequence. This is essentially a single method
>class whose method returns a double. Thus, for chart building I'm
>thinking of introspecting the model and returning all the methods that
>return a number. These can be wrapped in a dynamically compiled
>sequence. Something similar could be done for histograms.
>
>However, this approach sort of bothers me in that it assumes the methods
>of interest are already defined. Maybe we also need to iterate over all
>the agents calling some method on each one and then plot the average,
>for example. I don't want to do too much here as Tom and I are keen to
>get 2.0 out the door as its been a bit delayed as he and I have been
>writing models. So, any comments?

Disclaimer: I have very limited experience with introspection, so I
apologize if what I say is nonsense. [Although, in the last 30 mins
I've made some experiments, so it seems this may be doable.]

That said, what I originally had in mind was something like this:

a)
A menu with all the classes in the model's (?) package, you
could pick a class from it. (By default, it would be the model.)
Then, a menu of all the methods returning a value, PLUS all
the data members having a double/float/int/long/etc. type
would show up. You'd pick the data source from it.

b)
Alternatively, in the second step, the menu could show all
the collections (or perhaps, all arrays, too) available to
extract data from them [and calculate min/max/avg/sum].
It's much trickier, though, as with collections, you don't know
what kind of objects you are facing. So, perhaps, we should,
indeed, scale back to the agents... On the other hand,
we could force the user to pick a class/interface and throw
away all objects in the generated code that don't adhere...
(Although, I'm afraid this would get way too complicated for
the users...)

>Also, Gulya had a good suggestion about remembering the position and
>sizes of windows and so forth. If this is to be done between runs, but
>not between application instances then no problem. If we want to do it
>between application instances, and I think we do, then we'll need to use
>a file format to store this info. Java 1.4's new property mechanism
>would be good for this, but 1.4 is not really available for the Mac yet.
>So, I'm thinking a simple XML format. I'd go with java's properties
>format, but I think we'd might grow out of that at some time. We could

I haven't got much experience with java properties, so I don't know.
In principle, XML sounds good to me.

Take care! Gulya

[Repast-developer] custom charts question + properties

[Nick C. <nic...@ve...>]

Hi,

I've added support of the dynamic compilation of sequences and histogram
items for the various kinds of charts in repast. I've also fiddled with
the internals a bit so they should be a bit faster and look a bit
better. 

All this should make it fairly easy to create a chart building GUI so
the user can add charts on the fly. Data is received by a chart via some
class that implements Sequence. This is essentially a single method
class whose method returns a double. Thus, for chart building I'm
thinking of introspecting the model and returning all the methods that
return a number. These can be wrapped in a dynamically compiled
sequence. Something similar could be done for histograms. 

However, this approach sort of bothers me in that it assumes the methods
of interest are already defined. Maybe we also need to iterate over all
the agents calling some method on each one and then plot the average,
for example. I don't want to do too much here as Tom and I are keen to
get 2.0 out the door as its been a bit delayed as he and I have been
writing models. So, any comments?

Also, Gulya had a good suggestion about remembering the position and
sizes of windows and so forth. If this is to be done between runs, but
not between application instances then no problem. If we want to do it
between application instances, and I think we do, then we'll need to use
a file format to store this info. Java 1.4's new property mechanism
would be good for this, but 1.4 is not really available for the Mac yet.
So, I'm thinking a simple XML format. I'd go with java's properties
format, but I think we'd might grow out of that at some time. We could
also store the new display surface size now that we have draggable
resizeable surfaces (something I'd actually started before I saw Mile's
presentation!). We may also want to store dynamic charts (as described
above) between runs and instances. Comments?

Nick

-- 
Nick Collier 
Social Science Research Computing 
University of Chicago 
http://repast.sourceforge.net

Re: [Repast-developer] batch language

[Mark R. D. <mdi...@la...>]

Also, to give you an idea of how this looks in an Ant script here is one 
of my scripts (Note: my Model uses a Modified ParameterFileLoader class 
that loads single property values from a standard java properties file):

<?xml version="1.0" encoding="UTF-8"?>
<project basedir="." default="pva_analysis" name="PVA Batch Example">

    <!-- define my custom tasks here -->
    <taskdef name="batch" classname="org.mrd.ant.Batch">
        <classpath>
            <fileset dir="../../lib">
                <include name="**/*.jar"/>
            </fileset>
            <pathelement path="../../classes"/>
        </classpath>
    </taskdef>
    <taskdef name="beta" classname="org.mrd.ant.distributions.Beta">
        <classpath>
            <fileset dir="../../lib">
                <include name="**/*.jar"/>
            </fileset>
            <pathelement path="../../classes"/>
        </classpath>
    </taskdef>

    <!-- Define the batch targets here -->
    <target name="pva_analysis">
        <tstamp>
            <format pattern="yyyy_MM_dd-hh_mm_ss" property="time"/>
        </tstamp>
        <property name="pva_survivalMean" value="0.98"/>
        <property name="pva_survivalVar" value="0.015"/>
        <property name="pva_reproductionMean" value="0.55"/>
        <property name="pva_reproductionVar" value="0.05"/>
 
        <batch iterations="5" name="run">
            <!-- the iteration number gets stored under the property 
"run" -->
            <beta name="run_survial" mean="${pva_survivalMean}" 
std="${pva_survivalVar}"/>
            <beta name="run_reproduction" mean="${pva_reproductionMean}" 
std="${pva_reproductionVar}"/>
            <antcall target="createProperties"/>
            <antcall target="execute"/>
        </batch>
    </target>

    <target name="createProperties">
        <mkdir dir="./results/${time}/run_${run}"/>
        <propertyfile comment="PVA simulation Run # ${run}" 
file="./results/${time}/run_${run}/cagn.properties">
            <!-- Add parameters here to put into properties file -->
            <entry key="ModelInitialPairs" value="100"/>
            <entry key="ModelMaxIterations" value="500"/>
            <entry key="PairSurvivalProbability" value="${run_survial}"/>
            <entry key="PairReproductionProbability" 
value="${run_reproduction}"/>
        </propertyfile>
    </target>

    <target description="Running Simulation" name="execute">
        <java classname="org.mrd.examples.simple.Main" 
dir="./results/${time}/run_${run}" failonerror="false" fork="true">
            <arg value="-i"/>
            <arg value="'./cagn.properties'"/>
            <arg value="-h"/>
            <arg value="'../../../habitatspace.pgm'"/>
            <arg value="-l"/>
            <arg value="'../../../logconfig.xml'"/>
            <arg value="-b"/>
            <arg value="'../pva_results.txt'"/>
            <arg value="-r"/>
            <arg value="'run_results.txt'"/>
            <classpath>
                <pathelement location="../../classes"/>
                <!--pathelement location="G:\repast1.4\repast\src\src"/-->
                <fileset dir="../../lib">
                    <include name="**/*.jar"/>
                </fileset>
            </classpath>
            <jvmarg value="-Xms128m"/>
            <jvmarg value="-Xmx256m"/>
        </java>
    </target>

</project>

Re: [Repast-developer] batch language

[Mark R. D. <mdi...@la...>]

Nick Collier wrote:

>Hi,
>
>Any thoughts on a better batch description language? We have a sort of
>proto-XML format now together with the utterly confusing "}" based one.
>I'm thinking XML should do the job, but maybe something closer to a
>natural language would be better and then translate that into XML. Any
>thoughts? Examples?
>
>
>Nick
>
>  
>
I've discovered an Apache Jakarta Commons package called Jelly that 
really has caught my eye. Its similar in nature to Ant, but its built to 
be a "scripting" environment instead of a "build" environment. It can be 
embedded into any other java application (Servlet, Ant, "your 
application here"). It supports JSP style scripting (EL and tag 
libraries). I really was struggling with Ant in terms of writting tasks 
and passing around variables (getting the variables to update involved 
writting practically every task in another ant target), I think Jelly 
would really solve alot of my issues. Its supported and donated to to 
apache by a private company that promotes opensource release of its 
development projects. So I think it'll be around for awhile.

http://jakarta.apache.org/commons/sandbox/jelly/

donated by

http://www.werken.com/

So now I'm working twards implementing my batch stuff using this 
environment.

The other cool thing about Jelly, is that it can be bound to Java 
Objects. I can see actually calling the setters for my model parameters 
from within the Jelly script because I can instantiate the Model Object 
and manipulate it from within the script. Theoretically, by providing a 
sufficiently pluggable system of component Java Beans repast models 
could be "snapped" together using Jelly Script as well as utilizing 
Jelly's scripting env for batch processing.
 
-Mark

 p.s. I understand there's been some interest in my batch task in Ant. 
The Ant developers really "shun" any any development twards using Ant as 
a scripting environemnt, thus there are no <for-each>, <while> or any 
other conditional "type" tags in Ant.( This is where Jelly differs). My 
Batch task is simply an attempt to provide such conditional 
capabilities. It is in essance a simplified for loop.

Mostly what I was interested with Batch processing was to be able to 
"select" initial conditions from Probability Distributions (ie 
Beta(alpha,beta) or Normal(mean,std)). So I also wrote Distribution Rand 
Generator Tasks that can be used in Ant that are based on the Colt 
library (examples below).

Note: this code works with Ant 1.4.1 and isn't tested with Ant 1.5.x

-Mark

[Repast-developer] batch language

[Nick C. <nic...@ve...>]

Hi,

Any thoughts on a better batch description language? We have a sort of
proto-XML format now together with the utterly confusing "}" based one.
I'm thinking XML should do the job, but maybe something closer to a
natural language would be better and then translate that into XML. Any
thoughts? Examples?


Nick

-- 
Nick Collier 
Social Science Research Computing 
University of Chicago 
http://repast.sourceforge.net

[Repast-developer] java 1.4.x

[Nick C. <nic...@ve...>]

Hi,

I've just made some changes to the DefaultNode class to guarantee
predictable iteration order of adjacent nodes. In order do this, I
replaced a HashMap with a LinkedHashMap. Unfortunately, LinkedHashMap is
only available from 1.4 on. I'm not advocating the move to 1.4, and for
now this LinkedHashMap is provisional. I'm going to commit it anyway
though and we can work this out later. 

-- 
Nick Collier 
Social Science Research Computing 
University of Chicago 
http://repast.sourceforge.net

Re: [Repast-developer] Bug reports

[Nick C. <nic...@ve...>]

Hi again,

Do you mean that when you load a network from a file into a list of
nodes, the order of the nodes in the list is not predictable. This is
easy enough to fix, either by using a LinkedHashMap or sorting your
nodes once you have them in the list according to node id.

Nick

On Fri, 2002-09-20 at 11:39, Nick Collier wrote:
> Hi,
> 
> On Fri, 2002-09-20 at 11:24, Laszlo Gulyas wrote:
> > It is funny how long this went unnoticed [or at least, I've never heard of 
> > it].
> > Then, it's even funnier that within a week I came across three distinct 
> > examples.
> > One using the network library, the other working with multiple occupancy
> > spaces. The last one was in my own code, so I had no choice, but to nail
> > it down... ;-)
> > 
> 
> I can see how this would be a problem in if you used a HashMap / HashSet
> in your model and expected to be able reproduce the order of in which
> items are stored in the Map. However, I'm unclear about how this effects
> the network lib and multiple occupancy space. Can you explain further?
> There is a comment in the unordered Multiple occupancy space docs to the
> effect that the order of objects in a single cell is undefined; the
> implication being that you can't rely on the order.
> 
> thanks for the bug reports,
> 
> Nick
> 
> -- 
> Nick Collier 
> Social Science Research Computing 
> University of Chicago 
> http://repast.sourceforge.net
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Repast-developer mailing list
> Rep...@li...
> https://lists.sourceforge.net/lists/listinfo/repast-developer
-- 
Nick Collier 
Social Science Research Computing 
University of Chicago 
http://repast.sourceforge.net

Re: [Repast-developer] Bug reports

[Laszlo G. <gu...@la...>]

At 11:39 AM 9/20/2002 -0400, Nick Collier wrote:
>I can see how this would be a problem in if you used a HashMap / HashSet
>in your model and expected to be able reproduce the order of in which
>items are stored in the Map. However, I'm unclear about how this effects
>the network lib and multiple occupancy space. Can you explain further?
>There is a comment in the unordered Multiple occupancy space docs to the
>effect that the order of objects in a single cell is undefined; the
>implication being that you can't rely on the order.

OK, I overlooked this comment. So did Yuri, whose model's behavior depended
on it. But you're right, perhaps this is not a bug, but a feature. Not 
necessarily
one 'hay modelers' would like, though. :-)  I mean, if the modeler actually 
needs
to sort through the agents (i.e., activating them in some way), this feature
undermines replicability.

As for the network library, edges are stored in HashMap's in DefaultNode. And
since most models involve actually _doing_ something to your neighbors, people
usually tend to do something like getOutEdges() and iterate through them.
However, the _order_ in which they do may be important with respect to 
replicating
the results.

Again, this maybe just a warning issue. However, I feel like this might make
modelers rather uneasy. That said, I still like HashMap's! ;-0)

Gulya




>thanks for the bug reports,
>
>Nick
>
>--
>Nick Collier
>Social Science Research Computing
>University of Chicago
>http://repast.sourceforge.net

Re: [Repast-developer] Bug reports

[Nick C. <nic...@ve...>]

Hi,

On Fri, 2002-09-20 at 11:24, Laszlo Gulyas wrote:
> It is funny how long this went unnoticed [or at least, I've never heard of 
> it].
> Then, it's even funnier that within a week I came across three distinct 
> examples.
> One using the network library, the other working with multiple occupancy
> spaces. The last one was in my own code, so I had no choice, but to nail
> it down... ;-)
> 

I can see how this would be a problem in if you used a HashMap / HashSet
in your model and expected to be able reproduce the order of in which
items are stored in the Map. However, I'm unclear about how this effects
the network lib and multiple occupancy space. Can you explain further?
There is a comment in the unordered Multiple occupancy space docs to the
effect that the order of objects in a single cell is undefined; the
implication being that you can't rely on the order.

thanks for the bug reports,

Nick

-- 
Nick Collier 
Social Science Research Computing 
University of Chicago 
http://repast.sourceforge.net