<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">Hi.<br>
      I agree with Oli. Simply because we can is not enough reason to
      add something that would make<br>
      user code less generic<br>
      <br>
      We have thread parallel code that works both on structured and
      unstructured grids by<br>
      storing a vector of iterators and using each to forward iterate
      over one part of the grid.<br>
      Being able to store iterators in a vector and forward iterate is
      enough.for that.<br>
      This is hardly less efficient for structured grid then a random
      access iterator would be I think.<br>
      <br>
      The FD case us also not too convincing because there seems to be
      better ways of doing  it, ie.,<br>
      iterator::operator[](increment tuple) <br>
      which is different (and has nothing to do with STL.<br>
      <br>
      One question: <br>
      is it supposed to be guaranteed by the proposal that if an element
      K has index k then<br>
      it[k] would give me that element? There might be some use case for
      easily going from index to element although<br>
      I haven't really come up with an example. But I guess that
      wouldn't really be guaranteed anyway because that would<br>
      mean that one always iterates over the grid in the order of
      incrementing index.<br>
      <br>
      Best<br>
      Andreas<br>
      <br>
      On 01/10/14 11:51, Oliver Sander wrote:<br>
    </div>
    <blockquote cite="mid:542BDCB5.6000608@igpm.rwth-aachen.de"
      type="cite">
      <blockquote type="cite">
        <blockquote type="cite">
          <pre wrap="">- what is the use-case for random access iterators?
</pre>
        </blockquote>
        <pre wrap="">
One use case is for thread parallel assembly to split the iterator
range.
</pre>
      </blockquote>
      <pre wrap="">
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.

</pre>
      <blockquote type="cite">
        <pre wrap="">One other this is
intuition... why should yaspgrid only allow forward iterators if we
can compute everything directly in an efficient manner?
</pre>
      </blockquote>
      <pre wrap="">
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


</pre>
      <blockquote type="cite">
        <pre wrap="">
Ciao
Christian

</pre>
        <blockquote type="cite">
          <pre wrap="">Again, this is not to say that I object to the feature.
Cheers,
Oliver

Am 30.09.2014 um 23:17 schrieb Jö Fahlke:
</pre>
          <blockquote type="cite">
            <pre wrap="">Hi!

The random-access entity iterators are now ready for general review.
<a class="moz-txt-link-freetext" href="https://cgit.dune-project.org/repositories/dune-grid/log/?h=feature/random-access-entity-iterators">https://cgit.dune-project.org/repositories/dune-grid/log/?h=feature/random-access-entity-iterators</a>

@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
<a class="moz-txt-link-abbreviated" href="mailto:Dune-devel@dune-project.org">Dune-devel@dune-project.org</a>
<a class="moz-txt-link-freetext" href="http://lists.dune-project.org/mailman/listinfo/dune-devel">http://lists.dune-project.org/mailman/listinfo/dune-devel</a>

</pre>
          </blockquote>
          <pre wrap="">

</pre>
        </blockquote>
        <pre wrap="">


</pre>
        <blockquote type="cite">
          <pre wrap="">_______________________________________________
Dune-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Dune-devel@dune-project.org">Dune-devel@dune-project.org</a>
<a class="moz-txt-link-freetext" href="http://lists.dune-project.org/mailman/listinfo/dune-devel">http://lists.dune-project.org/mailman/listinfo/dune-devel</a>
</pre>
        </blockquote>
        <pre wrap="">

</pre>
      </blockquote>
      <pre wrap="">

</pre>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Dune-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Dune-devel@dune-project.org">Dune-devel@dune-project.org</a>
<a class="moz-txt-link-freetext" href="http://lists.dune-project.org/mailman/listinfo/dune-devel">http://lists.dune-project.org/mailman/listinfo/dune-devel</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>