dolfin team mailing list archive

[Johan Hake <hake@xxxxxxxxx>]

On Thursday 12 March 2009 10:32:10 Anders Logg wrote:
> On Thu, Mar 12, 2009 at 10:25:36AM +0100, Martin Sandve Alnæs wrote:
> > I have serious problems with the idea of letting user-defined
> > functions change nature to discrete functions as a side effect
> > of other operations, effectively hiding the user-defined implementation
> > of eval.
> >
> > (I know this concept wasn't introduced in this discussion, but it's
> > related).
>
> You mean by calling u.vector()? Yes, I agree it's problematic.
>
> But I don't know how to handle it otherwise. Consider the following
> example:
>
>   u = Function(V)

FYI:
u is a discrete function here. This is a difference between the python and c++ 
interface. Please shout if this is not what we want. The c++ base class of u 
is the cpp.DiscreteFunction defined SpecialFunctions.h. 

I did this mostly for avoiding the director wrapper attached to all python 
functions that inherits the cpp.Function, and with the assumption that when a 
Function is instantiated as:

  u = Function(V) 

you also want a discrete function. The only thing the DiscreteFunction does is 
instantiating the vector and defining some constructors that is used else 
where in the python interface.

Johan

>   solve(A, u.vector(), b)


> First u is a user-defined function since it doesn't have a
> vector. Then it becomes discrete when we ask for the vector.
>
> The problem I think is that there is no way for us to check whether a
> user has overloaded eval() without trying to call it.