dolfin team mailing list archive

[Johan Hake <johan.hake@xxxxxxxxx>]

On Thursday 10 December 2009 11:24:02 Garth N. Wells wrote:
> Johan Hake wrote:
> > 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.
> 
> I'm not too sure either.
> 
> 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.
> 
> This can be checked for using the shared_array member function 'unique()'.

Ok, but when will an array be unique? A user wrapping an array need to first 
construct a shared_array, pass it to an Array, and then it is not unique. Even 
if the user would not mind a method resizing the Array, it cannot if we use 
this as a control.

Johan

> Garth
> 
> > 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
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~dolfin
> > Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
> > Unsubscribe : https://launchpad.net/~dolfin
> > More help   : https://help.launchpad.net/ListHelp
>