dolfin team mailing list archive

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

Johan Hake wrote:
> On Thursday 10 December 2009 10:44:43 Anders Logg wrote:
>> 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.
> 
> Ok.
> 
>>> 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.
> 
> This works for most cases. 
> 
> What with eval where we, for now, can let the user pass a return array. Then 
> we cannot use the above syntax. I think we should keep the possibility to send 
> an array which is filled from the Python interface when ever this is possible. 
> However, it comes with some constraints on for example the resize function, 
> because such arrays cannot be resized. Maybe we can set a private attribute 
> owes_data which is set to true in the shared_array constructur, and which is 
> checked in the resize method?
> 
> I am not sure of the resize method with the shared_array. 

I'm not too sure either.

When resize should
> be safe, i.e., when we have used the shared_array constructor, we potentially 
> share the array with someone else. Then it could be dangerous to resize the 
> array.
>

This can be checked for using the shared_array member function 'unique()'.

Garth


> Johan
> 
>> --
>> 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
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~dolfin
> Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dolfin
> More help   : https://help.launchpad.net/ListHelp