dolfin team mailing list archive

["Garth N. Wells" <g.n.wells@xxxxxxxxxx>]

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.

> > /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

>   Johan
> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/mailman/listinfo/dolfin-dev