← Back to team overview

dolfin team mailing list archive

Re: [HG DOLFIN] Move code from Function copy?constructor to assignment operator and

 



Anders Logg wrote:
On Mon, Feb 16, 2009 at 12:11:42PM +0000, Garth N. Wells wrote:

Anders Logg wrote:
On Mon, Feb 16, 2009 at 11:44:04AM +0000, Garth N. Wells wrote:
Anders Logg wrote:
On Mon, Feb 16, 2009 at 11:30:46AM +0000, Garth N. Wells wrote:
Anders Logg wrote:
On Mon, Feb 16, 2009 at 11:52:54AM +0100, Johan Hake wrote:
On Monday 16 February 2009 11:31:36 Anders Logg wrote:
On Mon, Feb 16, 2009 at 10:12:21AM +0000, Garth N. Wells wrote:
Anders Logg wrote:
On Mon, Feb 16, 2009 at 10:36:52AM +0100, Johan Hake wrote:
On Sunday 15 February 2009 21:23:44 DOLFIN wrote:
One or more new changesets pushed to the primary dolfin repository.
A short summary of the last three changesets is included below.

changeset:   5701:d3661203791d9c7707695c59adbbd3a2e20a220c
tag:         tip
user:        Anders Logg <logg@xxxxxxxxx>
date:        Sun Feb 15 21:23:36 2009 +0100
files:       dolfin/function/Function.cpp
description:
Move code from Function copy constructor to assignment operator and
call assignment operator from copy constructor
I liked Garth solution better.

 1) A copy constructor that, just copies the Function if it has
    a FunctionSpace.
 2) The assignment operator works only for discrete Functions.

We could add an interpolate() (or something) function that

  v.interpolate(*_vector, *_function_space);
We already have exactly such a function.
Do we?
Yes:

  /// Interpolate function to given function space
  void interpolate(GenericVector& coefficients, const FunctionSpace& V) const;

Then the user can explicitly create a discrete function of its
user-defined Function. Now the user gets this as an implicitly result
of a function copy, which make litle sense to me.

But that's just me :)
I like it. Other opinions?
It is neat, but I would prefer any interpolation to be more explicit so
that it's clear what's going on. A copy should be a straight copy.

Garth
ok. I've changed it back. See if it looks ok.
Now a user cannot copy a Function that is not a discrete function, which was the case before we started all this.
Wasn't that the point? It's not possible to copy the eval() operator.

It is if a MyFunction object is copied to a MyFunction object, which we couldn't do before. My change made this possible.

Garth
What's the point of that? It's like copying half a Function.

No, it's a copy.
Only when assigning between two MyFunction objects.

If I do

  v = w;

I expect v to be in everything essential the same as w.

If you do

   MyFuncion f0;
   MyFunction f1 = f0;

f0 and and f1 will be the same. The assignment operator is a separate story.
What if you do
  MyFunction f0;
  MyOtherFunction f1 = f0;

?

I expect that you'll get an error when you try to call eval().

Garth

Not if MyOtherFunction has overloaded eval(). So then f1 might be
cos(x) although f0 is sin(x).


True.

So assignment from a user-defined function does not make sense unless
we interpolate.


It does make 'code' sense, but it does open the door for errors on the part of the user. The best solution may be to wind back the clock and just not allow the copying of user-defined functions. The only restriction imposed by this that I can think of is that a function can't return a user-defined Function.

Garth

If you just want to assign the FunctionSpace, then do

  MyOtherFunction f1(f0.function_space);



------------------------------------------------------------------------

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




Follow ups

References