dolfin team mailing list archive

[Kristian Ølgaard <k.b.oelgaard@xxxxxxxxx>]

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?

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
>