[dune-functions] [Dune-functions-commit] [Commit] dune-functions - 3979792: Add helper to directly access the type of nested children

[Steffen Müthing]

Hi,

> Am 10.09.2015 um 21:42 schrieb Carsten Gräser <graeser at mi.fu-Berlin.de>:
> 
> Am 10.09.2015 um 14:56 schrieb Steffen Müthing:
>> Hi,
>> 
>> 
>>> Am 10.09.2015 um 00:01 schrieb Carsten Gräser <graeser at mi.fu-Berlin.de>:
>>> 
>>> Am 09.09.2015 um 23:32 schrieb Christian Engwer:
>>>> shouldn't parts of these changes go to typetree?
>>> Yes, of course. This is true for most stuff in this header, but:
>>> 
>>> a) I'm not sure, if I have write access.
>>> b) I'd like to discuss this with Steffen before.
>> 
>> sorry for replying a little late…
> No problem.
>> 
>>> c) I can imagine that typetree already contains such functionality
>>>  and I just don't know where to find and how to use it.
>>> 
>> 
>> 
>> There is already something like ChildType in typetree, but its
> interface is a little less pretty. I finished
>> implementing the nice child(node,_1,3,_4,…) syntax yesterday (adding
> the SFINAE safeguards tripled
>> the size of the implementation), and that turns ChildType into a
> simple template alias to a decltype. I’ll
>> put that into typetree and push it as soon as I’ve written the
> documentation.
> Sound's nice.
> 
>> I had to discover that while I implemented a hybrid TreePath, it was
> never used and thus kind of ugly.
>> I’ll clean that up and put it into the implementation of dune-functions.
>> 
>> @Carsten: My implementation is basically built around a std::tuple as
> well, I just don’t use std::integral_constant
>> directly, but an inherited type fixed_index. Those types are also used
> for the fixed indices in the child method
>> (_1,_2), and when overloading those things, it’s just clearer to write
> fixed_index<i> instead of integral_constant<std::size_t,i>.
>> The Path itself also inherits from std::tuple, again mostly because it
> is clearer for anyone who has to read the code.
> Shouldn't we then still use plain integral_constant and make
> fixed_index a template alias. Seems to be cleaner and less
> surprising. For a type describing a static int, the user will
> expect integral_constant. If he tries to specialize for this
> it will not work.

I don’t like that idea, because it’s not clear what to specialize for, in particular
it’s not clear what to use for the type of the integral_constant. You’ve used int,
but typetree always uses std::size_t internally. That might create ugly surprises for
people… By really having fixed_index as a separate type, we make it much clearer
that the index type is part of the interface. And I *want* people to specialize / overload
using fixed_index because it increases code readability quite a bit.

> 
>> There is also a function in TypeTree that takes a TreePath and gets
> the corresponding child (but I’ll make that
>> forward to the new child method…).
> 
> I found one more thing that we could perhaps improve: Originally I
> thought that a PowerNode has a dynamic number of children. But that's
> not true. Hence we could describe the TreePath in a completely static
> way. But there's an issue with this: The PowerNode assumes that all
> children have the same type. If we want to store the TreePath in the
> nodes as we currently do, and use a fully static describtion, it will
> have a different type for all children. Hence the type of the children
> will differ and we can no longer use PowerNode. There's three possible
> solutions for this dilemma:
> 
> a)As a workaround, make the index for PowerNode children dynamic.
> b)Only use CompositeNode.
> c)Introduce a SemiPowerNode whose children are given as templates
> with a single parameter that is filled with the static index
> and require that the behaviour is exactly the same, up to the
> index.
> 
> b) can currently be done if you want to allow the compiler
> to optimize TreePaths away completely. c) looks like it will
> be a lot of work. a) is what we currently implement, on totally
> fine for me. I only wanted to point out these choices for completeness.

Yes, it’s a special case, and there are different trade-offs. When traversing a tree
using typetree’s applyToTree() algorithm, it is possible to choose between having a
fully dynamic or a fully static TreePath (the algorithm can do that because the TreePath
is generated during the tree traversal, and if you want a fully static index, it will just use
a TMP instead of a run time loop for PowerNode.

There are different approaches for this, but I think it is important to keep the invariant
that all children of a PowerNode have the exact same type because it reduces code size
and makes iteration easier for stuff like a Navier-Stokes assembler that can simply loop
over the children with a for loop. If you absolutely need the static index (from my experience,
you rarely do outside of some visitors, which have the information available anyway), use
a CompositeNode.

TL;DR: I also want to keep the status quo, even though it means having to ship around those
TreePath (on the other hand, that only happens once during construction anyway).

Best,
Steffen

> 
> Best,
> Carsten
> 
> 
> _______________________________________________
> dune-functions mailing list
> dune-functions at dune-project.org
> http://lists.dune-project.org/mailman/listinfo/dune-functions

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.dune-project.org/pipermail/dune-functions/attachments/20150911/ce93419e/attachment.sig>