dolfin team mailing list archive

[Johan Hake <johan.hake@xxxxxxxxx>]

On Tuesday October 19 2010 12:47:35 Kristian Ølgaard wrote:
> On 19 October 2010 20:59, Johan Hake <johan.hake@xxxxxxxxx> wrote:
> > On Tuesday October 19 2010 11:30:09 Kristian Ølgaard wrote:
> >> On 19 October 2010 19:36, Johan Hake <johan.hake@xxxxxxxxx> wrote:
> >> > On Tuesday October 19 2010 10:06:29 Kristian Ølgaard wrote:
> >> >> 2010/10/19 Johan Hake <johan.hake@xxxxxxxxx>:
> >> >> > On Tuesday October 19 2010 09:44:57 Anders Logg wrote:
> >> >> >> On Tue, Oct 19, 2010 at 06:19:52PM +0200, Kristian Ølgaard wrote:
> >> >> >> > On 19 October 2010 16:52, Anders Logg <logg@xxxxxxxxx> wrote:
> >> >> >> > > Kristian, is it time to move things over from newdoc to doc
> >> >> >> > > (and remove newdoc)?
> >> >> >> > 
> >> >> >> > Yes, I think we can do that. I was just looking at one of the
> >> >> >> > last issues which is translating type info from C++ syntax to
> >> >> >> > Python.
> >> >> >> 
> >> >> >> ok! Johannes, could you update the link/cronjob?
> >> >> >> 
> >> >> >> > I think we handle all the DOLFIN classes in a nice way using
> >> >> >> > e.g., _Mesh_ to create links, but for the built-in types, I
> >> >> >> > think that we should perhaps do the following:
> >> >> >> > 
> >> >> >> > For the *Returns* section, the first line should only contain
> >> >> >> > the type
> >> >> >> > 
> >> >> >> > such that for the Mesh::coordinates() function we will have:
> >> >> >> >     /// *Returns*
> >> >> >> >     ///     double*
> >> >> >> >     ///         Coordinates of all vertices.
> >> >> >> > 
> >> >> >> > instead of what we have now:
> >> >> >> >     /// *Returns*
> >> >> >> >     ///     An array of doubles
> >> >> >> >     ///         Coordinates of all vertices.
> >> >> >> > 
> >> >> >> > Then the 'double*' will be mapped to 'numpy.array(float)' (or
> >> >> >> > similar) for the Python programmer's reference, 'int* -->
> >> >> >> > 'numpy.array(int)' and 'std::vec<double>' --> 'list of floats'
> >> >> >> > etc.
> >> >> >> > 
> >> >> >> > For the *Arguments* section we can include the argument type
> >> >> >> > information in parenthesis just after the argument name such
> >> >> >> > that for
> >> >> >> > 
> >> >> >> > the Mesh::num_entities(uint d) function we will have:
> >> >> >> >     /// *Arguments*
> >> >> >> >     ///     d (integer)
> >> >> >> >     ///         Topological dimension.
> >> >> >> > 
> >> >> >> > instead of what we have now:
> >> >> >> >     /// *Arguments*
> >> >> >> >     ///     d
> >> >> >> >     ///         An integer, topological dimension.
> >> >> >> > 
> >> >> >> > For the former it will be easy to do search and replace to
> >> >> >> > handle the mapping. What do you think?
> >> >> >> 
> >> >> >> Sounds like a good solution!
> >> >> > 
> >> >> > +
> >> >> > 
> >> >> > What with more essoteric arguments and return values such as:
> >> >> > 
> >> >> >   std::vector<Foo>, Array<Foo>, std::pair<Foo, Bar>
> >> >> 
> >> >> I was planning to handle containers like the 'std::vector<uint>' as
> >> >> 'std::vec<> --> 'list of ' + 'uint' --> 'int'.
> >> > 
> >> > Some (all?) of std::vector<primitives>, Array<primiti> maps to
> >> > numpy.array(int).
> >> 
> >> OK, where should I look to figure out what the types map to? I'm sure
> >> we can create some relatively simple rule by looking at the container
> >> and the types which they contain to sort this out.
> > 
> > All Array<some primitive> should map to the corresponding numpy.array.
> > Some few std::vector<some primitive> maps to numpy.arrays. We have tried
> > to get rid of all these, but I they still excists as argout typemaps.
> > Meaning that typical where a std::vector<some primitive>& is used to get
> > values. Methods
> 
> > that use the argout typemap:
> Is this info only in the typemap.i, or is it scattered in all the *.i
> files?

The Array typemaps are defined in array_typemaps.i. The std::vector typemaps 
are defined in std_vector_typemaps. And the std::pair typemaps are defined in 
typemaps.i

Some structure, but there could probably be more...

Johan

> Kristian
> 
> >  GenericMatrix_getrow
> >  GenericMatrix_setrow (probably wrongly...)
> >  IntersectionOperator_all_intersected_entities
> >  Mesh_all_intersected_entities
> >  + some MPI functions (probably wrongly...)
> > 
> >> >> In your example 'Foo'
> >> >> should really be '_Foo_' because we will insert a link to the DOLFIN
> >> >> class 'Foo'.
> >> > 
> >> > std::vector<*Foo> maps to 'a list of Foo'.
> >> > 
> >> >> So Array<Foo> should be _Array_<_Foo_> and this case is already
> >> >> handled in the current setup.
> >> >> 
> >> >> What does std::pair map to in Python anyway? I get
> >> >> 
> >> >> >>> mesh = dolfin.UnitSquare(1,1)
> >> >> >>> point = dolfin.Point(0.0, 2.0)
> >> >> >>> mesh.closest_point_and_cell(point)
> >> >> 
> >> >> <Swig Object of type 'std::pair< dolfin::Point,dolfin::uint > *' at
> >> >> 0x94820b0>
> >> > 
> >> > Hmpfrr... bad example ;) Other std::pair maps to a tuple of the
> >> > returned arguments.
> >> 
> >> I expected a tuple, so when will it be a tuple and when will it be
> >> something like the above which I don't know how to put in a
> >> programmer's reference?
> > 
> > Wrapping of primitives are really easy. It is done last in the typemap.i.
> > For no are only:
> > 
> >  std::pair<dolfin::uint,dolfin::uint>
> >  std::pair<dolfin::uint,bool>
> > 
> > implemented. I need to do some research to fix the
> > 
> >  std::pair<Foo,Bar>
> > 
> > where Foo can be a dolfin class (a la Point) or a primitive.
> > 
> > Johan
> > 
> >> Kristian
> >> 
> >> >> I expect to treat it similarly to std::vec and with <Foo, Bar> =
> >> >> <_Foo_, _Bar_>.
> >> > 
> >> > Johan
> >> > 
> >> >> Kristian
> >> >> 
> >> >> > Johan
> >> >> > 
> >> >> >> --
> >> >> >> Anders
> >> >> >> 
> >> >> >> > Kristian
> >> >> >> > 
> >> >> >> > > I see there have been a couple of important bug fixes,
> >> >> >> > > including the template parse error.
> >> >> >> > > 
> >> >> >> > > If so, could Johannes update the cronjob to fix this?
> >> >> >> > > 
> >> >> >> > > 
> >> >> >> > > _______________________________________________
> >> >> >> > > Mailing list: https://launchpad.net/~dolfin
> >> >> >> > > Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
> >> >> >> > > Unsubscribe : https://launchpad.net/~dolfin
> >> >> >> > > More help   : https://help.launchpad.net/ListHelp
> >> >> >> 
> >> >> >> --
> >> >> >> Anders
> >> >> >> 
> >> >> >> _______________________________________________
> >> >> >> 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