[SciPy-dev] solver classes (was: help: wrapping generalized symmetric evp functions)

Robert Cimrman cimrman3@ntc.zcu...
Fri Apr 11 04:08:08 CDT 2008


Ondrej Certik wrote:
> To get the discussion going, here are some comments. Everyone please
> let us know what you think:
> 1)
>> s = Solver.anyFromConf( conf, mtx = A ) # Possible pre-solves by LU.
> How about this:
> s = Solver(conf, mtx = A )

This certainly could be done, by it looks confusing to me - 
instantiating a generic Solver and getting an instance of something else 
(a particular solver). I prefer slightly more a static method here, with 
some better name, e.g. Solver.create_any() or whatever.

> and also this (together with the syntax above):
> s = Solver(kind="ls.scipy_iterative", method="cg", mtx = A )

The same here. Also note that in some cases the configuration dictionary 
can be quite large, so having one argument name reserved for 'conf' or 
'config' or ... seems ok to me. Anyway, this way of constructing a 
solver suits best some general framework where the code does not know in 
advance which particular solver a user might need (like it is e.g. in 
sfepy - it just needs to know the type of a solver (linear, nonlinear, 

> This is useful for reading the configuration from some file. However,
> sometimes (a lot of times) I prefer this:
> 2) how about this:
> class SciPyIterative(LinearSolver):
>     blabla
> class CG(SciPyIterative):
>     pass
> class Umfpack(LinearSolver):
>     pass
> and people would just use:
> from scipy.sparse.linalg import CG, Umfpack
> s = CG(epsA=1e-6, mtx=A)
> or
> s = Umfpack(mtx=A)

Yes, this is what I like to have, too. If you solve a particular 
problem, you construct a particular solver directly. (But note that you 
can already do that with the classes as they are now in sfepy... Again, 
the Solver.anyFromConf()-like syntax is useful more for an abstract 
framework than for a use in small scripts.)

> 3) I also prefer to pass the matrix as the first argument, becuase you
> always need to supply a matrix, only then some optinal default
> arguments, or preconditioners, i.e.:
> s = CG(A, epsA=1e-6)
> or
> s = Umfpack(A)

In linear solvers, yes. Other types of solvers might not need a matrix 
at all. All solvers have a configuration, though. So there is some logic 
in as it is, but 'conf' can be made a keyword argument, then why not.

We should also use something_and_something convention instead of 
somethingAndSomething for the argument names, as it is usual in SciPy.

thanks for the comments,

More information about the Scipy-dev mailing list