dolfin team mailing list archive

["Garth N. Wells" <gnw20@xxxxxxxxx>]

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?

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