On Thursday 07 May 2009 23:16:54 Anders Logg wrote:
On Thu, May 07, 2009 at 11:05:49PM +0200, Johan Hake wrote:
On Thursday 07 May 2009 18:54:04 Anders Logg wrote:
I've added some of the requested features to the parameter system,
some pushed and some sitting here in a local repository. But the
current design makes it a pain to add new features. A single change
will make it necessary to add a function in at least 5 different
classes.
So I'm thinking of reimplementing and simplifying the parameter
system. I think I know how to make it simpler.
But before I do that, does anyone have opinions on the
design/implementation? Is there any third-party library that we
could/should use (maybe something in boost)?
It would be nice to have something that easely could be transferable to
Python.
Having a base class let say Parameterized and then let all inherit this
to be able to define parameters will not work well for the shared_ptr
interface we have. We have problems with the Variable class, which does
not work for the derived shared_ptr classes e.g. Function. I would rather
have classes that have a parameter rather than beeing.
How would that work? Inheritance now provides get/set functions for
subclasses making it possible to do
solver.set("tolerance", 0.1);
Not sure what you ask for here. I know of Parametrized and I agree that the
above syntax is nice. But I prefer to keep the parameters in its own object
and just operate on that. These can then be collected into one "dict/map" and
then form the parameters of an application. This is also easier to wrap to
python.
The shared_ptr argument might not be so relevant as the potential parametrized
classes may not be declared as shared_ptr classes in the swig interface
anyway. However if that will be the case we must declare Parametrized as a
shared_ptr class in swig and then we must declare all Parametrized sub
classes as shared_ptr...
Also by defining a parameter(list/dict) class which can be accessed as a
dict let us make the transition to python smoother.
ParameterDict p = solver.default_params();
p["abs_tol"] = 1e-9;
It would need to be
ParameterDict& p = solver.default_params();
Sure :P
and I'd suggest naming it Parameters:
Parameters& p = solver.parameters();
Fine.
By defining some templated check classes we could controll the
assignment. In the Solver:
...
ParameterDict& default_params(){
if (!_par)
{
_par = new ParameterDict();
_par->add_param("abs_tol",new RangeCheck<double>(1e-15,0,1));
vector<string> * allowed_prec = new Vector<string>();
allowed_prec->push_back("ilu");
allowed_prec->push_back("amg");
allowed_prec->push_back("jacobi");
_par->add_param("prec",new
OptionCheck<string>("ilu"),allowed_prec));
_par->add_param("nonsense","jada"); // No checks
}
}
Well, I admit that the above code is not beautiful, and others can
probably make it cleaner and spot errors. The point is that RangeCheck
and OptionCheck can be derived from a ParCheck class that overloads the
operator=(). This will just call a private set function which is defined
in the derived classes, and which do the check.
I think we can also solve this without excessive templating... ;-)
Good!
The to and from file can be implemented in the ParameterDict body. The
checks do not have to be written or read, as a ParameterDict can only
read in allready predefined parameters, and the check will be done when
the file is read.
The option parser ability can also be implemented in ParameterDict using
boost or other libraries, based on the registered parameters.
I have implemented something like this in Python, and the above is a try
to scetch something similare in c++.
What exactly is needed from the Python side? I think I can make a
fairly simple implementation of this in C++ using a minimal amount of
templates with simple syntax.
Using operator[] to get and set parameters can straightforwardly be mapped to
python, and we can then also implement the map/dict protocol on top of that.
Other get and set methods can also be used, however set is a built in type in
Python and not a good alternative.
Is the main difference that instead of inheriting Parametrized, a
subclass needs to implement a method named parameters() which returns
the parameter "dictionary"?
Yes.
