dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

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.

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

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

Attachment: signature.asc
Description: Digital signature