[dune-functions] [Dune-functions-commit] [Commit] dune-functions - c7b3989: Resize must now be done manually before interpolate()

[Oliver Sander]

Hi Carsten,

>> Yes, but if you start with this in dune-functions we'll have another
>> sizeable chunk of dune-pdelab functionality in there soon.  We may
>> decide to go that way, but I recall that at least originally the claim was
>> 'no vector backends in dune-functions'.
> But without backends, a basis is just an ordered set of functions.
> Then we must also drop things like interpolate or *BasisGridFunction
> because they require to link vectors with bases.
Yes, that is a dilemma.  But we may then be honest and acknowledge that the
current backend implementation implicitly assume that the vector data types
are istl types.  Consequently, the backend should/could have 'istl' in their names.


>
>> However, I am not against vector backends in general.  I just don't want
>> them forced onto users of "simple" bases.
> I'd also not add a bunch of backends, just the trivial one that bridges
> the gap from the multi-index (1,2,3) to [1][2][3].
Alternatively, we could extend istl to do that for us.  istl is all about nested data structures,
so it would be logical to allow something like operator[](TreePath) there.

Best,
Oliver


>
>>> Even for the simple p1 example you cannot pass the multi-index
>>> directly but have to explain the appended [0]. This is exactly
>>> what the backend encapsulates.
>> ... which is kind-of ugly, as a matter of fact.  I keep thinking that maybe
>> we should replace array<size_t,1> by size_t whenever that appears as
>> a multi-index.
> But this would mean to teach users things that will not work
> in general. Even worse you cannot write code that works in both,
> the simple and not so simple cases. If you really think it's so ugly
> we may consider to derive from array and add a cast to size_t
> in the simple case. However I'd prefer to hide the complicated
> multiindex stuff in a simple wrapper (that's the backend) that
> can also be explained easily.
>
> Best,
> Carsten
>
>>> Maybe a cleaner solution would be, to provide some kind of vector
>>> adaptor providing operator()(MultiIndex) and a hierachic resize.
>>> Then we would write
>>>
>>>   SomeVector v;
>>>   auto&& v_coeff = basisCoefficients(v, basis);
>>>   v_coeff.resize();
>>>   interpolate(v_coeff, treePath, f);
>>>
>>> This would also allow to exchange the now hard wired backend
>>> more easily.
>> Possibly.
>>
>> Best,
>> Oliver
>>
>>> Best,
>>> Carsten
>
>
> _______________________________________________
> dune-functions mailing list
> dune-functions at dune-project.org
> http://lists.dune-project.org/mailman/listinfo/dune-functions

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dune-project.org/pipermail/dune-functions/attachments/20150915/14cddb14/attachment.htm>