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

Oliver Sander oliver.sander at tu-dresden.de
Tue Sep 15 10:31:43 CEST 2015


Hi Carsten,
> in fact the assumptions are not at all istl specific;
yes I know.  But my point is that the backend does make assumptions about
the linear algebra library.

>
> a)All nested containers must provide operator[](size_type).
> b)All nested containers up to a certain nesting level
>   must provide resize(size_type).
> c)All containers above this level have static size but no resize().
>
> Hence you could easily use nested standard containers like
> 'vector<vector<array<double,2>>>' and in the example we really
> do use 'vector<vector<char>>'. So 'istl' would be misleading.
>
>>>> 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.
> On the one hand I like this idea, because it would be very convenient.
> But I'm afraid, that people will complain (and perhaps that's partly
> true):
>
> "We also have some index access scheme, namely nested operator[].
> If we add operator[](MultiIndex) for dune-functions, will we add
> also add get(MultiIndex), operator()(MultiIndex), ... if that's
> convenient for another library? Just write a wrapper for it!"
>
> For the moment I propose to keep the wrapper in dune-functions
> and adjust the basis interface such that we don't need it for
> flat indices. And if we are convinced that this is a good
> interface, we may propose it for istl.
>
> 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/aa367b71/attachment.htm>


More information about the dune-functions mailing list