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
signature.asc
Description: Digital signature
_______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
