dolfin team mailing list archive
-
dolfin team
-
Mailing list archive
-
Message #13365
Re: Parameter system
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);
> 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();
and I'd suggest naming it Parameters:
Parameters& p = solver.parameters();
> 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... ;-)
> 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.
Is the main difference that instead of inheriting Parametrized, a
subclass needs to implement a method named parameters() which returns
the parameter "dictionary"?
--
Anders
Attachment:
signature.asc
Description: Digital signature
Follow ups
References