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