dolfin team mailing list archive

["Garth N. Wells" <gnw20@xxxxxxxxx>]

While you're at it with wrapping MeshFunction, I added

    MeshFunction(const Mesh& mesh, uint dim, const T& value)

a while ago (not the const T& value at the end). It would be nice if
this could be used from Python too. Saves calling the 'set' function.

Garth

On Mon, 2010-08-16 at 10:53 -0700, Johan Hake wrote:
> 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
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~dolfin
> Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dolfin
> More help   : https://help.launchpad.net/ListHelp