dolfin team mailing list archive

[Johan Hake <hake@xxxxxxxxx>]

On Saturday 18 October 2008 21:24:53 Anders Logg wrote:
> On Thu, Oct 16, 2008 at 03:38:01PM +0200, Martin Sandve Alnæs wrote:
> > "in" is a reserved keyword in python. Suggestions: "f.in_space(V)" or
> > "f.in_function_space(V)" or "f.member(V)"
>
> How about keeping u.in(V) in C++ and then map it to something suitable
> in Python so that one may write
>
>   if u in V:
>       ...
>
> in Python. Does anyone know how to do that?

There is a problem in the logic here. In c++ you ask the function if it is in 
a certain FunctionSpace, but the python code "u in V" would check if u is in 
V by calling V.__contains__(u). To make it more consistent we could implement 
the 'in' function in FunctionSpace, and then just rename 'in' to 
__contains__. 

You could also keep it the way it is and then rename Function.in to let say 
Function._in and then extend FunctionSpace with

  def __contains__(self,u).
      assert(u,Function)
      return u._in(self)

But then we would have different logics in c++ and python.

Johan

> > As mentioned before, these are not threadsafe:
> >
> >     /// Access current cell (available during assembly for
> > user-defined function)
> >     const Cell& cell() const;
> >
> >     /// Access current facet (available during assembly for
> > user-defined function)
> >     uint facet() const;
> >
> >     /// Access current facet normal (available during assembly for
> > user-defined function)
> >     Point normal() const;
> >
> > If we keep these instead of making them arguments to eval,
> > the user must create one Function for each thread to use
> > it in a parallell shared memory application.
>
> Not necessarily one Function for each thread, but it should be
> possible to extend Function to keep one cell etc for each thread.
> The variables are accessed by functions cell(), facet() so it should
> be possible to hide it.