[Dune-devel] Random-Access Iterators

[Andreas Dedner]

Hi.
I agree with Oli. Simply because we can is not enough reason to add
something that would make
user code less generic

We have thread parallel code that works both on structured and
unstructured grids by
storing a vector of iterators and using each to forward iterate over one
part of the grid.
Being able to store iterators in a vector and forward iterate is
enough.for that.
This is hardly less efficient for structured grid then a random access
iterator would be I think.

The FD case us also not too convincing because there seems to be better
ways of doing  it, ie.,
iterator::operator[](increment tuple)
which is different (and has nothing to do with STL.

One question:
is it supposed to be guaranteed by the proposal that if an element K has
index k then
it[k] would give me that element? There might be some use case for
easily going from index to element although
I haven't really come up with an example. But I guess that wouldn't
really be guaranteed anyway because that would
mean that one always iterates over the grid in the order of incrementing
index.

Best
Andreas

On 01/10/14 11:51, Oliver Sander wrote:
>>> - what is the use-case for random access iterators?
>> One use case is for thread parallel assembly to split the iterator
>> range.
> That doesn't convince me.  People will want to do thread-parallel assembly
> on unstructured grids as well, and we will need to invent something to allow
> that.  On the other hand, for thread-parallel assembly you need less that
> full random access.
>
>> One other this is
>> intuition... why should yaspgrid only allow forward iterators if we
>> can compute everything directly in an efficient manner?
> Because for the last ten years we have been telling people that forward
> iteration is enough, and that you don't actually need random access.
>
> Best,
> Oliver
>
>
>> Ciao
>> Christian
>>
>>> Again, this is not to say that I object to the feature.
>>> Cheers,
>>> Oliver
>>>
>>> Am 30.09.2014 um 23:17 schrieb Jö Fahlke:
>>>> Hi!
>>>>
>>>> The random-access entity iterators are now ready for general review.
>>>> https://cgit.dune-project.org/repositories/dune-grid/log/?h=feature/random-access-entity-iterators
>>>>
>>>> @Carsten: are you willing to include this in 2.4, provided noone finds any
>>>>           serious issues?
>>>>
>>>> A grid declares that certain entity iterators are random-access by doing
>>>>
>>>>   typedef std::random_access_iterator_tag iterator_category;
>>>>
>>>> in the iterator implementation class.  The facade class Dune::EntityIterator
>>>> notices this and defines the additional methods needed for random access
>>>> iterators in terms of the member functions advance(n) and distanceTo(otherIt)
>>>> of the iterator implementation class.  If your grids entity iterators do
>>>>
>>>>   typedef std::forward_iterator_tag iterator_category;
>>>>
>>>> or omit the member type completely, the EntityIterator will be a forward
>>>> interator, as before.
>>>>
>>>> To do this, Dune::EntityIterator no longer implements the iterator methods
>>>> itself, but derives from Dune::EntityIteratorBase, which has a template
>>>> parameter category to select which type of iterator to implement.  Previously
>>>> the ancestry looked like
>>>>
>>>>   EntityPointer
>>>>   EntityIterator
>>>>
>>>> now it looks like (for forward iterators)
>>>>
>>>>   EntityPointer
>>>>   EntityIteratorBase<..., std::forward_iterator_tag>
>>>>   EntityIterator
>>>>
>>>> or (for random access iterators)
>>>>
>>>>   EntityPointer
>>>>   EntityIteratorBase<..., std::forward_iterator_tag>
>>>>   EntityIteratorBase<..., std::random_access_iterator_tag>
>>>>   EntityIterator
>>>>
>>>> The template argument list of EntityIterator is completely the same as before.
>>>>
>>>> There is one function that has been omitted from random access iterators for
>>>> the time being, namely operator[].  There are three possibilities for the
>>>> return type of operator[]: Either return the entity by value -- but that needs
>>>> copyable entities, which are not ready yet.  Or return a reference to the
>>>> entity -- not possible, since we have nothing that stores that entity.  Or
>>>> return a proxy object -- but I'm too lazy to implement that, since we will
>>>> have copyable entities soon.  Note that instead of the (currently) invalid
>>>> expression "it[n]" you can write "*(it+n)": The + creates a temporary
>>>> iterator that holds the entity.
>>>>
>>>> I also omitted implementing bidirectional iterators, since I could not come up
>>>> with a use case for iterating backwards through the grid.  If a grid declares
>>>> an iterator implementation as bidirectional, the resulting EntityIterator will
>>>> nevertheless just be a forward iterator.  It should be easy to add
>>>> bidirectional iterators, should the need arise.
>>>>
>>>> Regards,
>>>> Jö.
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Dune-devel mailing list
>>>> Dune-devel at dune-project.org
>>>> http://lists.dune-project.org/mailman/listinfo/dune-devel
>>>>
>>>
>>
>>
>>> _______________________________________________
>>> Dune-devel mailing list
>>> Dune-devel at dune-project.org
>>> http://lists.dune-project.org/mailman/listinfo/dune-devel
>>
>
>
>
> _______________________________________________
> Dune-devel mailing list
> Dune-devel at dune-project.org
> http://lists.dune-project.org/mailman/listinfo/dune-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dune-project.org/pipermail/dune-devel/attachments/20141001/be8d8be6/attachment.htm>