dolfin team mailing list archive
-
dolfin team
-
Mailing list archive
-
Message #16976
Re: [Branch ~dolfin-core/dolfin/main] Rev 4340: Work on SWIG interface of Array and Expression
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.
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
Follow ups
References