dolfin team mailing list archive

[Johan Hake <johan.hake@xxxxxxxxx>]

On Thursday 10 December 2009 15:03:50 Garth N. Wells wrote:
> 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.
> 
> Could you have a look at it now?

On to it. Not sure I am able to push anything within the first hour. 

Soon dinner time here ;)

Johan
 
> Garth
> 
> > 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
>