dolfin team mailing list archive

[Johan Hake <johan.hake@xxxxxxxxx>]

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:

  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