dolfin team mailing list archive

[Johan Hake <johan.hake@xxxxxxxxx>]

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.

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