← Back to team overview

dolfin team mailing list archive

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