Re: Parameter Managers and all that...

[Wojtek Kopczuk]

Hi,
> On 31 Mar, address@hidden wrote:
> Those of you who have implemented parameter managers of one sort
> or another, could you summarize your approach and your implementation?
> 

It seems to me that everybody implements his own parameter manager :).
Let me describe my (or rather Rick Riolo's modified by myself) approach.
The features that we found most important for parameter manager:
1 it should be possible to set parameter values from the command line
or from a file
2 it should also be possible to specify values of the parameters
on the run-time
3 there should be some GUI interface to the parameter manager making
it possible to change parameter values interactively
4 we need range constraints imposed on parameters
5 accessing the parameter value should be fast
6 many multiple managers can coexist - each related to a different
swarm
7 it would be nice to have aliases for parameters (for example
when you specify parameter of the value in the command line it 
would be useful to have a short name for parameter, for other
purposes it is better to have a long meaningful name)

Implementation:
We have a root class representing a generic parameter manager.
Parameters are defined in the subclass of the parameter manager 
as its attributes. Parameter manager methods allow to have
it initialized from both file and command line (goals 1 and 2).
We do not use ObjectLoader because it cannot recognize aliases.

The single parameter is represented by an RParameter object
inheriting from VarProbe. The standard VarProbe class was 
redefined to have an ability to perform range checking - it 
has methods to set range of variables and its methods setData:To: and 
setData:toString: are redefined so that they control 
whether the value is outside the range. Also a parameter
object knows its alias. The parameter value is always set
using setData: methods so that we achieve goal 4.

GUI: parameter manager can be probed. Its ProbeMap consists of
the probes for its variables - in this case these are
instances of RParameter class (we can do so because it is a subclass
of VarProbe). What we gain is that when value of the parameter
is set from the GUI, range checking is performed  (so we have
achieved goal 3 without violating 4)

All of the RParameter objects are stored in a parameter collection
being of a map type. The same parameter can be stored under its name 
and under names of its aliases. Thus accessing parameter is
relatively fast when accessing element in the map is fast.
In addition an agent can get a RParameter object once, store it
somewhere and use it to get/set parameter value without dealing with
the whole parameter manager.

Drawbacks: there is one serious problem, namely the fact that
VarProbe class is redefined, so some changes in the future
implementations of probes can possibly affect behavior of the
parameter manager. 
However: one thing that seems pretty clear
to me is that VarProbe should have an ability to perform range
checking as it is very common for the parameters to have some 
limits imposed on them. 

Wojtek
-- 
-----------------------------------------------------------
Wojtek Kopczuk              "There is no third way between
address@hidden       right and wrong"
IGS: wojtek                  Friedrich von Hayek 
http://www.econ.lsa.umich.edu/~wojtek
-----------------------------------------------------------

                  ==================================
   Swarm-Support is for discussion of the technical details of the day
   to day usage of Swarm.  For list administration needs (esp.
   [un]subscribing), please send a message to <address@hidden>
   with "help" in the body of the message.
                  ==================================