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

[Oliver Sander]

Hi,
> a)We derive MultiIndex<class size_type, size_type i> from e.g.
>   array and implement the cast to size_type for i=1.
this sounds nice.  However, this is basically the same trick that is supposed
to make FieldVector<T,1> look like a plain T.  In my experience that never really
worked.  On the other hand, the interface of a multi-index is much more restricted
than that of a FV, so maybe the approach works better here.


> b)The result of basis.size() without prefix is no longer
>   the same as the one with an empty prefix, but an object
>   providing operator()(Prefix) and a cast to size_type.
>   In the trivial case the result of this cast should be
>   either the same as for an empty prefix or as dimension.
That's your proposal from 0:49, right?  I kinda like that.
Best,
Oliver

>
> Then we can use a simple vector if the index is flat
> or a wrapped hierarchic one in other cases.
>
> Carsten
>
> Am 15.09.2015 um 00:49 schrieb Carsten Gräser:
>> Hi Oliver,
>>
>> Am 14.09.2015 um 22:55 schrieb Carsten Gräser:
>> [...]
>>>> ... 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.
>>> 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
>>>
>>>>> 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.
>>>> Possibly.
>> if this is implemented as operator[] instead and the cast proposed
>> above is also implemented it has the nice side effect, that we can
>> (almost) use a flat vector in simple cases and a wrapped one in the
>> complicated ones. It's only 'almost', because we have to write
>>
>>   v.resize(basis.size());
>>
>> in the simple case, whereas we need something like
>>
>>   v.resize(basis);
>>
>> in the complicated ones. If we change the interface of basis.size()
>> without prefix to return some object that provides all size information
>> we can even get around this.
>>
>> Best,
>> Carsten
>>
>>
>>
>>>> Best,
>>>> Oliver
>>>>
>>>>> Best,
>>>>> Carsten
>>>
>>>
>>> _______________________________________________
>>> dune-functions mailing list
>>> dune-functions at dune-project.org
>>> http://lists.dune-project.org/mailman/listinfo/dune-functions
>>>
>>
>>
>>
>> _______________________________________________
>> dune-functions mailing list
>> dune-functions at dune-project.org
>> http://lists.dune-project.org/mailman/listinfo/dune-functions
>>
>
>
>
> _______________________________________________
> 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/e1841f30/attachment.htm>