[Dune] [#848] add index method to GeometryType (Attachment added)

[Dune]

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.

The following task has a new comment added:

FS#848 - add index method to GeometryType
User who did this - Jö Fahlke (joe)

----------
I have a patch for this which I am however not really satisfied with.  It
introduces a continuous index which can be obtained from a GeometryType object
gt by gt.index().  The index runs as follows:

  Point         -> 0
  (none,0)      -> 1
  Line          -> 2
  (none,1)      -> 3
  Triangle      -> 4
  Quadrilateral -> 5
  (none,2)      -> 6
  Tetrahedron   -> 7
  ...

i.e. Geometries of higher dimensions have bigger indices, within a given
dimension none is sorted after regular regometries and regular geometries are
sorted according to their topologyId with the last bit ignored.

You can extract the number of indices up to a given dimension d either
statically using

  Dune::GeometryTypeSize<d>::value

or dynamically using

  Dune::geometryTypeSize(d)

Both will return 2 for d=0, 4 for d=1, 7 for d=2, 12 for d=3 etc.

There are two issues I have with this implementation:

1. To find the number of indices for a given dimension only, you have to say
   geometryTypeSize(d)-geometryTypeSize(d-1).  This is problematic when d
   happens to be 0.  Also, to obtain an index only within a given dimension to
   have to write gt.index()-geometryTypeSize(d-1), which is again problematic
   for d=0.

   We might want to change them to return 0 for d=0, 2 for d=1, 4 for d=2, 7
   for d=3, 12 for d=4 etc., but then we should also think of better names.

2. The ordering of the indices does not agree with the ordering of
   GeometryTypes using operator<().  While the index sorts by

     dimension, regular/none, topologyId>>1

   (most important criterion first), operator<() sorts by

     regular/none, dimension, topologyId>>1

   This may be surprising for some users.  The ordering for the indices is
   necessary to lump all indices for a particular dimension together, but
   maybe we can change the behaviour of operator<()?  AFAIK that is used for
   std::map only, some people might depend depend on the order of the entries
   in the map.  Of course, it only makes a difference when none is involved,
   so it may not be such a big deal.

----------

One or more files have been attached.

More information can be found at the following URL:
http://www.dune-project.org/flyspray/index.php?do=details&task_id=848#comment2369

You are receiving this message because you have requested it from the Flyspray bugtracking system.  If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.