← Back to team overview

dolfin team mailing list archive

Re: Documentation

 

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.

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

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
>



Follow ups

References