dolfin team mailing list archive

[Johan Hake <johan.hake@xxxxxxxxx>]

On Monday August 16 2010 10:34:01 Anders Logg wrote:
> On Mon, Aug 16, 2010 at 10:28:10AM -0700, Johan Hake wrote:
> > On Monday August 16 2010 10:07:41 Anders Logg wrote:
> > > On Mon, Aug 16, 2010 at 09:57:26AM -0700, Johan Hake wrote:
> > > > On Monday August 16 2010 05:51:24 noreply@xxxxxxxxxxxxx wrote:
> > > > > ------------------------------------------------------------
> > > > > revno: 4986
> > > > > committer: Anders Logg <logg@xxxxxxxxx>
> > > > > branch nick: dolfin-dev
> > > > > timestamp: Mon 2010-08-16 14:48:44 +0200
> > > > > 
> > > > > message:
> > > > >   Implement named MeshFunctions in Python. Might be a better way
> > > > >   (using
> > > > > 
> > > > > SWIG magic).
> > > > 
> > > > I think it is fine. The only reason we would like to wrap it using
> > > > SWIG would be to preserve the types. So one could check if a passed
> > > > MeshFunction is for example a VertexFunction. But I think we should
> > > > not encourage that and instead use dim.
> > > 
> > > ok.
> > > 
> > > > When I looked at the Python implementation I wonder if we should
> > > > harmonize the data type setting with NumPy. Instead of 'int' pass
> > > > either int or 'i', and so on.
> > > > 
> > > > If you agree, do you know of any other place where we could do such a
> > > > harmonizing?
> > > 
> > > Isn't the problem that with "uint" we get the expected type (that
> > > matches dolfin::uint in C++). Last time I checked, the NumPy list of
> > > int types is a jungle of different options.
> > 
> > Yes, but we have setled in the NumPy typemaps on the correct one. It is
> > to use "I" or unit32 for unsigned int. This will not be any problem
> > eitherway as these types are just used to instantiate the correct
> > MeshFunctionFoo. in the same "switch" statement we have now.
> 
> I imagine "uint" is easier since that is used in C++, or maybe it's
> simple for me because I'm working on the DOLFIN C++ code and see a lot
> of "uint"...

Maybe I am confused because I always think in typical numpy types. Then I can 
add the possibility to use the NumPy types while keeping the old ones?

> > > > I also think it is better to implement the named MeshFunctions as
> > > > inheriting from MeshFunction, instead of just beeing functions that
> > > > returns. I can fix this.
> > > 
> > > I tried but it didn't work (the constructors were not called) but I'm
> > > sure you know how to fix it. :-)
> > 
> > Just use __new__:
> >   class VertexFunction(MeshFunction):
> >     "Create MeshFunction of topological dimension 0 on given mesh."
> >     
> >     def __new__(self, value_type, mesh):
> >         return MeshFunction.__new__(self, value_type, mesh, 0)
> 
> Why?

I assume you tried using __init__? Something like:

 class VertexFunction(MeshFunction):
    "Create MeshFunction of topological dimension 0 on given mesh."
    def __init__(self, value_type, mesh):
        MeshFunction.__init__(self, value_type, mesh, 0)

An __init__ method is only called if the object returned from __new__, which 
is called implicitly befor __init__, is of the _same_ type as the class we are 
defining. As VertexFunction inherit MeshFunction its __new__ will eventually 
be called together with the provided arguments, which is for example 

   "uint", mesh

What MeshFunction.__new__ returns are then an empty MeshFunctionUInt, because 
this is what MeshFunctions("uint", mesh) gives you. As MeshFunctionUInt is not 
of the same type as MeshFunction or VertexFunction, its __init__ will not be 
called and we will get an empty meshfunction.

If we instead overload __new__ we can manipulate what is returned from the 
class initialization. Instead of calling MeshFunction.__new__ 
VertexFunction.__new__ is called.

Comprendo?

Johan