dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Thu, Jul 13, 2006 at 06:41:28PM +0200, Garth N. Wells wrote:
> On Thu, 2006-07-13 at 17:20 +0200, Johan Jansson wrote:
> > On Thu, Jul 13, 2006 at 04:56:29PM +0200, Anders Logg wrote:
> > > On Thu, Jul 13, 2006 at 04:54:43PM +0200, Johan Jansson wrote:
> > > > On Thu, Jul 13, 2006 at 01:02:29PM +0200, Garth N. Wells wrote:
> > > > 
> > > > ...
> > > > 
> > > > > Johan, any news on wrapping the uBlas functions? It would be good to
> > > > > sort this out before proceeding too far with the linear algebra clean
> > > > > up. We could change uBlasMatrix to look like
> > > > > 
> > > > >   template<class Mat>
> > > > >   class uBlasMatrix : public Variable, public GenericMatrix, 
> > > > >                       public uBlasKrylovMatrix
> > > > >   {
> > > > >     public:
> > > > >       .
> > > > >       .
> > > > > 
> > > > >     private:
> > > > >       Mat* mat;
> > > > >   }
> > > > > 
> > > > > Would this work with Swig?
> > > > 
> > 
> > ...
> > 
> > > Which part of the uBlas interface for a uBlasSparseMatrix will we
> > > export? If we are not exporting anything more than what is in the
> > > interface of uBlasSparseMatrix (including GenericMatrix), then we
> > > don't need to make uBlasSparseMatrix a subclass of the uBlasMatrix
> > > template anyway and could have a uBlasMatrix as a private member as in
> > > the PETSc wrappers.
> > ...
> > > As far as I can tell, the advantage of the templating to reduce code
> > > size would still remain even if we make uBlasMatrix<...> a private
> > > member. Would then the only argument to have the uBlas wrappers as
> > > subclasses of a template the convenience when working directly through
> > > the original uBlas interface in C++?
> > > 
> 
> I don't quite follow this.

I meant there seem to be two main advantages of the current template
design. One is that it avoids duplication of code for different uBlas
types and the other is that it makes it more convenient to use DOLFIN
uBlas matrices since they can actually do much more than just the
simple GenericMatrix interface - all the uBlas calls are available
directly.

My point was that if we can avoid duplication of code also with a
private member to the actual implementation as in the PETSc wrappers,
then the only advantage would be the convenience.

But the problem would still be the private member which should be a
pointer to the implementation. To specify a type for the pointer, one
would still need to make uBlasMatrix a template. Is the problem with
SWIG templates in general or just inheriting from a template?

> > > /Anders
> > 
> > I think (but I could have misunderstood) the advantage is that
> > templates allow us to define a single uBlasMatrix (which could be
> > defined as above, i.e. the same design as for PETSc) for sparse and
> > dense matrices. Then we can just declare:
> > 
> > typedef uBlasMatrix<ublas_sparse_matrix> uBlasSparseMatrix;
> > 
> > typedef uBlasMatrix<ublas_dense_matrix> uBlasDenseMatrix;
> > 
> > If we're not allowed to define template classes, then we need to
> > duplicate the code in uBlasSparseMatrix and uBlasDenseMatrix. This is
> > a consequence of uBlas using templates instead of inheritance to
> > define its matrix types.
> > 
> 
> This is how I see it.
> 
> What's the conclusion? Is it likely that a limited part of uBlas can be
> successfully wrapped for SWIG without too much difficulty?
> 
> I was planning to test using tuples, which are part of Boost (they are
> planned to be part of the next C++ standard). They are really useful for
> functions that return more than one argument (handy for iterative
> solvers which may return info like number of iterations, converged
> true/false, number of restarts, residual). Is this likely to pose any
> problems for SWIG?  
> 
> Garth

Don't know how well this plays with SWIG, but it would definitely be
something natural to have in the Python interface:

    (converged, iterations, residual) = GMRES.solve(A, x, b)

So it's worth looking into.

/Anders