← Back to team overview

dolfin team mailing list archive

Re: Matrix aritmetic operators

 

2008/9/28 Anders Logg <logg@xxxxxxxxx>:
> On Sun, Sep 28, 2008 at 10:56:41PM +0200, Johan Hake wrote:
>> On Sunday 28 September 2008 09:51:41 Anders Logg wrote:
>> > On Sat, Sep 27, 2008 at 11:46:42PM +0200, Johan Hake wrote:
>> > > Hello!
>> > >
>> > > Occasionally we have had some discussion about implementing a basic
>> > > aritmetic operators for matrices in DOLFIN. I have been able to add -=,
>> > > +=, +, -, operators, for the PETScMatrix interface, using the petsc
>> > > function MatAXPY. I also implemented both assignment operators.
>> > >
>> > > I added a public function add(A,a), which add a GenericMatrix, A, scaled
>> > > by a, to the present matrix. This is a usefull funtion when combining
>> > > matrices in a linear algebra setting. The function is also used to
>> > > implement the +=, and -=, which then are used to implement +, - together
>> > > with the assignment operator.
>> > >
>> > > Is this something we want? I would at least like it to happen :)
>> >
>> > I think this sounds excellent.
>> >
>> > > Do I miss any important aspects? What about two distributed matrices?
>> > > Will PETSc AXPY take care of this, (supposing of course that the matrices
>> > > have the same number of nonzeros)?
>> >
>> > I think so (if that's what "Collective on Mat" means).
>> >
>> > > If we add the "add" function in the GenericMatrix interface we could
>> > > implement the +=, -= operators directly in the GenericMatrix interface,
>> > > together with both + and - using +=, -=. This is a good solution for at
>> > > least PETSc and Epetra Matrix that do not implement its own += and -=,
>> > > which uBLAS and MTL4 do.
>> > >
>> > > I have it going for PETScMatrix. Should I implement this interface to
>> > > GenericMatrix, and update the other dolfin Matrix classes too? The
>> > > changes in GenericMatrix would be:
>> > >
>> > >   1) remove explicit from the copy constructor, to allow "return by
>> > >   value"
>> >
>> > Why is the copy constructor explicit? I might have forgotten something
>> > but wasn't the conclusion that we should make all constructors
>> > explicit except copy constructors? Martin?
>>
>> In email from 8.7.2008 you come with this conclusion. The email thread ended
>> with your post, and it seems that nothing more happened. Not having too much
>> c++ expearience, it took me two hours to figure out that it was the explicit
>> keyword that made my implementation not work...
>>
>> Anyway, in my upcomming patch I can remove the explicit in the copy
>> constructors.
>
> Fine with me. The only problem I see might be that Martin has some
> obscure (but valid) reason for keeping it. But he'll let us know. :-)

I don't. But do you really want return by value? Using shared pointers
inside will make it cheap, but then operations that modify the shared
data should copy it first to keep the "by value" real.

--
Martin


References