<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Carsten,<br>
<pre wrap="">
</pre>
<blockquote cite="mid:55F73439.4090302@mi.fu-berlin.de" type="cite">
<blockquote type="cite">
<pre wrap="">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'.
</pre>
</blockquote>
<pre wrap="">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.</pre>
</blockquote>
Yes, that is a dilemma. But we may then be honest and acknowledge
that the<br>
current backend implementation implicitly assume that the vector
data types<br>
are istl types. Consequently, the backend should/could have 'istl'
in their names. <br>
<br>
<br>
<blockquote cite="mid:55F73439.4090302@mi.fu-berlin.de" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">However, I am not against vector backends in general. I just don't want
them forced onto users of "simple" bases.
</pre>
</blockquote>
<pre wrap="">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].</pre>
</blockquote>
Alternatively, we could extend istl to do that for us. istl is all
about nested data structures,<br>
so it would be logical to allow something like operator[](TreePath)
there.<br>
<br>
Best,<br>
Oliver<br>
<br>
<br>
<blockquote cite="mid:55F73439.4090302@mi.fu-berlin.de" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">... 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.
</pre>
</blockquote>
<pre wrap="">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
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">Possibly.
Best,
Oliver
</pre>
<blockquote type="cite">
<pre wrap="">Best,
Carsten
</pre>
</blockquote>
</blockquote>
<pre wrap="">
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
dune-functions mailing list
<a class="moz-txt-link-abbreviated" href="mailto:dune-functions@dune-project.org">dune-functions@dune-project.org</a>
<a class="moz-txt-link-freetext" href="http://lists.dune-project.org/mailman/listinfo/dune-functions">http://lists.dune-project.org/mailman/listinfo/dune-functions</a>
</pre>
</blockquote>
<br>
</body>
</html>