dolfin team mailing list archive

[Johan Hake <johan.hake@xxxxxxxxx>]

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 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.

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
>