dolfin team mailing list archive

[Johan Jansson <johanjan@xxxxxxxxxxxxxxxx>]

On Fri, Aug 11, 2006 at 05:08:38PM +0200, Garth N. Wells wrote:
> The problem is that any functions that are defined in 
> GenericMatrix/GenericVector have some overhead due to the functions 
> being virtual. When accessing elements of a uBlas vector/matrix within a 
> loop this becomes noticeable.

Ok. But I guess we're using the uBlas interface (via DenseVector or
DenseMatrix) anyway when we need fast indexing or element-wise
operations?

> >We can then define nice operators in Python for these functions with
> >__getitem__()/__setitem__():
> >
> >    def __setitem__(self, i, a):
> >        if(isinstance(i, int)):
> >            self.setelement(i, a)
> >        elif(isinstance(i, tuple)):
> >            self.setelement(i[0], i[1], a)
> >
> >In C++, the uBlas indexing interface already exists, so we can use that.
> >
> 
> Is the issue with SWIG being unable to wrap uBlas a problem here? I can 
> add indexing functions to uBlasMatrix and uBlasVector with no 
> performance penalty if that helps.
> 
> Garth
> 

I think the issue is maintainability and consistency. Even if we could
wrap the uBlas interface with SWIG, that would still mean that Vector
would have two different syntaxes for indexing. This is why I want to
define a complete interface via GenericVector/GenericMatrix. I don't
want to be in a situation where code breaks because the interface is
different depending on whether you compiled with PETSc or not. It's
also really confusing.

Indexing is never going to be fast via Python anyway, a Python
function call is very slow to begin with. So performance is not an
issue when we're talking about the Python interface. You never want to
perform a loop with an element-wise operation in Python, except
possibly for initialization or something like that, where performance
isn't so important.

  Johan