<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hi Carsten,<br>
    <blockquote cite="mid:55F7D629.8000702@mi.fu-berlin.de" type="cite">
      <blockquote type="cite">
        <pre wrap="">
</pre>
      </blockquote>
      <pre wrap="">in fact the assumptions are not at all istl specific;</pre>
    </blockquote>
    yes I know.  But my point is that the backend does make assumptions
    about<br>
    the linear algebra library.<br>
    <br>
    <blockquote cite="mid:55F7D629.8000702@mi.fu-berlin.de" type="cite">
      <pre wrap="">

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.

</pre>
      <blockquote type="cite">
        <blockquote type="cite">
          <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>
        <pre wrap="">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.
</pre>
      </blockquote>
      <pre wrap="">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


</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>