← Back to team overview

dolfin team mailing list archive

Re: New Function implementation

 

Johan Hake wrote:
On Sunday 19 October 2008 00:24:36 Anders Logg wrote:
On Sat, Oct 18, 2008 at 11:55:32PM +0200, Johan Hake wrote:
On Saturday 18 October 2008 23:23:24 Anders Logg wrote:
On Sat, Oct 18, 2008 at 10:16:32PM +0200, Johan Hake wrote:
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
I think that would be ok, considering it is Python that maps "in" to
"contains". The logic and notation from a user perspective would be
the same in C++ and Python:

  if (u.in(V))
  {

  }

  if u in V:
I see your point and I agree.

My logical error was attached to who implemented what. But to get the
nice and from a user perspective logical syntax you present above, we
need to implement it differently in c++ and python.
ok, good. Can you implement it?

Yes, but I would like to have Martins feedback on how 'pythonic' the implementation is. In most regards will the python version, "u in V" answer the question "is u an item in V", where V is interpreted as a sequence or container. The function, u is strictly speeking not an item in V. You can for example not access u from V.

It's just a gut feeling I have that we might stretch the python interface a bit here. This is maybee not a bad idea when you have the somewhat minimalistic function name 'in' from c++ in mind, but if you have a pure python background it could be a bit confusing. I think I would go for the _slightly_ more verbal u.in_space(V) implementation. You should not avoid two word function name for all cost ;)


I might be butting in here, but isn't the main idea of the special Python methods __contains etc, precisely the possibility of decoupling the abstraction idea from the implementation?

Here, I imagine that the point is to represent a mathematical abstraction - whether a function is an element of a function space. In my opinion, the syntax

   if u in SpaceOfPiecewiseSomething:
does this well.

--
Marie E. Rognes
Ph.D Fellow, Centre of Mathematics for Applications, University of Oslo
http://folk.uio.no/meg



References