dolfin team mailing list archive

[Johan Hake <johan.hake@xxxxxxxxx>]

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).

> 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 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