<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
Hi Carsten,<br>
<blockquote cite="mid:55F6D092.8090409@mi.fu-berlin.de" type="cite">
<pre wrap="">there are two parts to this question:
a)Should we expect the user to resize manually?
we could simply call this in the interpolate method. But the result of
calling this will be rather complicated to describe for a nested vector,
especially because we only write into a subset of components in general
and it's hard to give proper defaults. For me it's much cleaner to say,
that the user has to resize on its own.
For this simple example you could also simply do
dirichletNodes.resize(feBasis.size());
Making it easier to the eye. But this expects knowledge
about the implementation details of the basis and interpolate.</pre>
</blockquote>
I'd prefer if the 'interpolate' method would set the correct sizes
at least<br>
for the simple cases. Having to resize manually clutters up the
user code.<br>
Also, I find it difficult to explain to newbies why the
implementation of a<br>
simple standard basis does not know/must not use the number of basis<br>
functions.<br>
<br>
<blockquote cite="mid:55F6D092.8090409@mi.fu-berlin.de" type="cite">
<pre wrap="">
b)Should we expose the backend stuff?
The basis itself does only provide indices and does not tell,
how to map them to a specific container implementation. But
each time you want to interpolate, or construct a grid function
from coefficients and basis, you need to pass mutiindices and
size information to the containers nested operator[] and resize().</pre>
</blockquote>
Yes, but if you start with this in dune-functions we'll have another<br>
sizeable chunk of dune-pdelab functionality in there soon. We may<br>
decide to go that way, but I recall that at least originally the
claim was<br>
'no vector backends in dune-functions'.<br>
<br>
However, I am not against vector backends in general. I just don't
want<br>
them forced onto users of "simple" bases.<br>
<br>
<br>
<blockquote cite="mid:55F6D092.8090409@mi.fu-berlin.de" 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>
... which is kind-of ugly, as a matter of fact. I keep thinking
that maybe<br>
we should replace array<size_t,1> by size_t whenever that
appears as<br>
a multi-index.<br>
<br>
<br>
<blockquote cite="mid:55F6D092.8090409@mi.fu-berlin.de" 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>
Possibly.<br>
<br>
Best,<br>
Oliver<br>
<br>
<blockquote cite="mid:55F6D092.8090409@mi.fu-berlin.de" type="cite">
<pre wrap="">
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>