dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Mon, Jul 10, 2006 at 08:06:16PM +0200, Garth N. Wells wrote:
> On Mon, 2006-07-10 at 19:09 +0200, Johan Jansson wrote: 
> > On Mon, Jul 10, 2006 at 02:26:19PM +0200, Garth N. Wells wrote:
> > 
> > > My first implementation of DenseMatrix worked something like this. I
> > > changed it later because it didn't seem very elegant given that uBlas is
> > > written in C++. Also, it's not possible to access member functions of
> > > uBlasMatrixImplementation without a wrapper function or directly working
> > > with the pointer to uBlasMatrixImplementation. 
> > 
> > Why is it a problem to work with the pointer? Isn't it a good idea to
> > work with uBlasMatrix if you want to use the GenericMatrix interface,
> > and to work with uBlasMatrixImplementation (or
> > ublas_sparse_matrix/ublas_dense_matrix) if you want to use the uBlas
> > interface?
> > 
> 
> It might be  possible to first get the pointer to
> uBlasMatrixImplementation before doing anything, but I prefer not to
> (could be because I'm lazy). Besides my laziness, it might not be so
> simple. If we use the same design as PETScSparseMatrix, I'm pretty sure
> that it's not possible to have a pointer
> 
>     uBlasMatrixImplementation* mat;
> 
> if uBlasMatrixImplementation is templated. It needs to be
> 
>     uBlasMatrixImplementation<matrix_type>* mat;
> 
> How do we deal then with the different matrix_type.

If we should follow the same approach as for the PETSc wrappers, then
the pointer should be to a uBlas native type, not to another DOLFIN
class.

And it should probably a reference (two versions, one const) instead
of a pointer. The pointer in the PETSc case is just because PETSc Mat
is a pointer and the PETSc functions assume to get a pointer.

If we decide to do it like this, it shouldn't increase the amount of
code we need to maintain since uBlasMatrix already needs to implement
the interface of GenericMatrix.

/Anders


> Garth 
> 
> > > 
> > > Would it help if rather than having 
> > > 
> > >    typedef uBlasMatrix<ublas_sparse_matrix> uBlasSparseMatrix;
> > > 
> > > we have 
> > > 
> > >    class  uBlasSparseMatrix : uBlasMatrix<ublas_sparse_matrix> {};?
> > > 
> > > Garth
> > > 
> > 
> > This doesn't help unfortunately. uBlasMatrix<ublas_sparse_matrix> is
> > not instantiable without knowing what ublas_sparse_matrix is. The
> > result is that SWIG ignores it and uBlasSparseMatrix becomes empty.
> > 
> >   Johan
> 
> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/mailman/listinfo/dolfin-dev