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

[Carsten Gräser]

Hi Oliver,

Am 15.09.2015 um 09:45 schrieb 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.
in fact the assumptions are not at all istl specific;

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


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