dolfin team mailing list archive

[Johan Hake <johan.hake@xxxxxxxxx>]

On Thursday 10 December 2009 10:44:43 Anders Logg wrote:
> On Thu, Dec 10, 2009 at 10:33:42AM -0800, Johan Hake wrote:
> > On Thursday 10 December 2009 10:17:46 Garth N. Wells wrote:
> > > Johan Hake wrote:
> > > > On Wednesday 09 December 2009 01:08:38 Garth N. Wells wrote:
> > > >> noreply@xxxxxxxxxxxxx wrote:
> > > >>> ------------------------------------------------------------
> > > >>> revno: 4340
> > > >>> committer: Johan Hake <hake.dev@xxxxxxxxx>
> > > >>> branch nick: dolfin
> > > >>> timestamp: Tue 2009-12-08 23:42:50 -0800
> > > >>> message:
> > > >>>   Work on SWIG interface of Array and Expression
> > > >>>    - Need to sort out what we want:
> > > >>>
> > > >>>         Array<const double>& or const Array<double>&
> > > >>>
> > > >>>      The latter is to prefer when constructing typemaps
> > > >>
> > > >> The latter looks nicer, but since Array wraps a pointer, I don't
> > > >> know how to create an Array<double> from a const double* pointer
> > > >> without using const_cast.
> > > >
> > > > Yes, I used that in the old eval calling the new eval. Would this be
> > > > an issue once we have removed the old eval? I did not try it, but I
> > > > just assume it would be difficult to make a const double * out of a
> > > > double * but now I see that this is the easy one ;) If we want the
> > > > prior one, I can try to change it back.
> > >
> > > I'm about to commit code where I've changed it back in the C++
> > > interface. I don't see at the moment how to avoid Array<const double>
> > > since we often use Array to wrap a const pointer. For example, Data has
> > > member data
> > >
> > >   Array<const double> x;
> > >
> > > and we update frequently the array to which x points.
> >
> > Fine, I did not have time to do it yesterday. If you have not done it, I
> > can update the SWIG interface code.
> >
> > Should we change all double* and uint* to Array? There are still some
> > left in the low level la interface. This would make it possible to erase
> > all numpy_typemaps.
> 
> I think so, or at least in all functions that we wrap to Python.

Ok.

> > I am also not sure the boost::shared_array works for all circumstances of
> > memory management. Not sure this case is relevant, but say we have a
> > method that returns an Array. Instead of returning the Array we want to
> > return a NumPy array. Then we have to let the NumPy array take control of
> > the data.
> 
> I don't think it happens that often. The C++ interface never (?)
> returns data from function other than simple scalars.
> 
> If we have
> 
>   void compute_foo(Array& x);
> 
> in C++, then it should be wrapped to
> 
>   x = compute_foo()
> 
> in Python and then some glue code will be needed anyway and that code
> would first create NumPy array, wrap that into an Array and send it to
> compute_foo.

This works for most cases. 

What with eval where we, for now, can let the user pass a return array. Then 
we cannot use the above syntax. I think we should keep the possibility to send 
an array which is filled from the Python interface when ever this is possible. 
However, it comes with some constraints on for example the resize function, 
because such arrays cannot be resized. Maybe we can set a private attribute 
owes_data which is set to true in the shared_array constructur, and which is 
checked in the resize method?

I am not sure of the resize method with the shared_array. When resize should 
be safe, i.e., when we have used the shared_array constructor, we potentially 
share the array with someone else. Then it could be dangerous to resize the 
array.

Johan

> --
> Anders
> 
> > Is this possible with the boost::shared_array? I was thinking of using a
> > private is_view attribute instead?
> >
> > The nice thing with shared_array is that we can control the ownership
> > through two nice and simple constructors.
> >
> > Johan
> >
> > > Garth
> > >
> > > >>>    - Compiled expression call now kind off works:
> > > >>>
> > > >>>         e = Expression('sin(x[0])')
> > > >>>         e(pi/2,0) == 1
> > > >>>
> > > >>>    - Array.array() returns a NumPy view of the data.
> > > >>>
> > > >>>    - Need to clean up the SWIG code...
> > > >>
> > > >> Should we add a file 'Array.i'? Then it's clear where all the Array
> > > >> magic happens.
> > > >
> > > > Not sure it will work out properly. We need to put the class
> > > > specializations in common_{pre,post}.i, and then we need the typemaps
> > > > a head of everything, as we handle most of the other typemaps today.
> > > > This is a minor detail as common is the first module to be included
> > > > in interface, but it is at least consistent with the other SWIG
> > > > interface files.
> > > >
> > > > I put the Array typemap in function_pre.i temporarily, as it
> > > > otherwise would interfere with the copy-constructor of Array. We can
> > > > easily avoid this by calling the argument 'other' instead of 'x' in
> > > > the copy constructor.
> > > >
> > > > Johan
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~dolfin
> > Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
> > Unsubscribe : https://launchpad.net/~dolfin
> > More help   : https://help.launchpad.net/ListHelp
>