dolfin team mailing list archive

[Johan Hake <johan.hake@xxxxxxxxx>]

On Thursday 04 March 2010 10:48:35 Anders Logg wrote:
> On Wed, Feb 24, 2010 at 06:12:29PM -0800, Johan Hake wrote:
> > On Tuesday 23 February 2010 11:48:05 Anders Logg wrote:
> > > I thought that Array should be automagically mapped to Numpy arrays in
> > > Python. This doesn't happen for the new component() function I just
> > > added to FunctionSpace.
> > >
> > > Test by
> > >
> > >   mesh = UnitSquare(4, 4)
> > >   V = VectorFunctionSpace(mesh, "CG", 1)
> > >   print V.sub(0).component()
> >
> > No they are not.
> >
> > I think we landed on doing this on case to case. You can just call
> > V.sub(0).component().array().
> >
> > The blueprint on the array typemap is not closed. There still exist some
> > questions we need to sort out, including (I think) this one.
> >
> > I cannot come up with a good example just now why we shouldn't just wrap
> > all out Arrays to numpy arrays, but I think it had something to do with
> > ownership and possibilities of returning an array that potentially might
> > be resized.
> 
> Could you try wrapping all Arrays by default?
> 
> It would be useful at least for
> 
>   FunctionSpace::component()
>   TimeSeries::vector_times()
>   TimeSeries::mesh_times()
> 
> All of these return an Array. It would be natural for these to return
> a Python list (or tuple) in Python.
> 
> The first one returns a const reference. If it helps I can change it
> so it returns by value.
> 
> The other two return an Array by value.
> 
> Perhaps the natural thing would be for return-by-value Arrays to map
> to Python tuples?

I have now added a typemap for all methods that return an 
Array<{double,uint,int}> by value. The Arrays are mapped to NumPy arrays. 

Even if one could consider other return types, it would have been very complex 
to keep track on the different cases.

Johan