[dune-functions] [Dune-devel] hierarchicVectorWrapper and hierarchicMatrixWrapper

[Carsten Gräser]

Hi Simon,

Am 23.02.2018 um 14:48 schrieb Simon Praetorius:
> Hi Carsten,
> 
>>> A common coefficient type is really a tricky problem. For
>>> MultiTypeVector<std::vector<std::bitset<N>>, std::vector<bool>>
>>> for example, there is no common value type. Both leaf vectors
>>> return different (non-compatible) proxies for the boolean values.
>> that's why it is _impossible_ to implement a non-const
>> access to this with a dynamic index (unless you implement
>> some possibly slow type-erasure).
> 
> Actually, it is possible (without type-erasure), but you need
> an additional wrapping functor (like the MultIndexResolver) for
> the leaf access. OK, it does not really return a mutable reference
> to the vector values (since this is impossible with the static type
> system of c++, as you mentioned), but instead one could implement
> something like an assignment-proxy for the mutable access and some
> value-proxy for the const-access. With this technique, I have implement the
> hierarchicWrapperTest for the
> MultiTypeVector<std::vector<std::bitset<N>>, std::vector<bool>>.
> But, to be honest, this solution is not so very nice. You have two
> wrapping functors and you need a terminal operation, like assignment
> or value comparison. So it's maybe not what we want here.
implementing this will lead to very nasty code, because
you have to ensure that your functor compiles for all
possible vector entry types showing up in your nested
vector. You can surely rule out types (for the non-selected
branches) by SFINAE and replace them by a dummy functor.
But then you cannot ensure statically that your functor
is called at all and a bug in your SFINAE expression can
only be detected as runtime error.

For these reasons I really don't like this approach. 

>>> OK. I simply have not seen/tried out any basis that is not
>>> a DefaultGlobalBasis. Some parts of my implementation are
>>> based on the PreBasis structure of Power/Composite PreBases
>>> This is probably too restrictive, but I have no other idea currently.
>> The problem is not that the structure is needed to implement
>> this information. The problem is that the interface depends
>> on this.
> 
> Maybe I get this wrong. The pure vector-datastructure does not encode
> the hierarchy we need for the recursion, since e.g. the leaf nodes could
> also be
> vector types. The coefficient type could be a break condition for the
> recursion,
> but must be provided. The nesting-structure could also be a break
> condition for
> the recursion, but must also be provided.
> The nesting-structure itself is not directly related to a (pre)basis or
> its implementation. It is just a light-weight description of the hierarchy.
> So, it can be described independently of the basis, but could also be
> extracted
> from the basis.
> The last step is tightly coupled to the concrete prebasis
> datastructure and implementation, currently. This is probably not the
> best solution.
You would not want to provide this manually. Which means
the basis interface has to be extended to export this.
But since the approach does not satisfactorily solve some
of the problems (see above) I'm not sure if this is the
way to go. Also I don't think that hard-wiring several
different vector interfaces (istl, mtl) is a good idea.
In this sense the name `HierarchicVectorWrapper` is really
misleading.

After some discussion with Oliver I came to the conclusion,
that we probably don't want to support vector-valued coefficients
in the long run, because this is more naturally represented
by a power-basis in dune-functions. Hence we can avoid a lot
of the problems by terminating on scalar entries. I implemented
this in `istlVectorBackend()`:

  https://gitlab.dune-project.org/staging/dune-functions/merge_requests/108

This is mostly a cleaned-up version of HierarchicVectorWrapper
that removes some of the (partly dysfunctional) automagic
by dropping support for vector-valued coefficients. Support
for this could be added (at the price of knowing the type),
but I don't think that this is needed (see above). It is also
tied to ISTL/STL-like vector interfaces. For other vector
interfaces (MTL) you can simply implement other VectorBackends
providing the same interface/concept.

This does _not_ solve the problem of different coefficient types.
But as I explained above I  don't think that the approach you
proposed solves this either. I have the impression that a real
solution to this would be to provide static multi-indices.
This should solve all the problems on the users side. However,
implementing this inside of the pre-basis is not so trivial.
Furthermore this interface extension should be discussed before.

Best,
Carsten

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: <https://lists.dune-project.org/pipermail/dune-functions/attachments/20180326/4069ae3e/attachment.sig>