22 Oct
2008
22 Oct
'08
8:27 p.m.
#168: Revamp mln::topo::internal::complex_data<D>
--------------------------+-------------------------------------------------
Reporter: levill_r | Owner: levill_r
Type: enhancement | Status: new
Priority: major | Milestone: Olena 1.0
Component: Milena | Version: 1.0
Resolution: | Keywords: cleanup
--------------------------+-------------------------------------------------
Old description:
See
source:branches/cleanup-2008/milena/mln/topo/complex.hh
* Store only the indices of adjacent faces in `complex_data<D>`: we
don't really need actual faces there, and it costs a lot (memory,
execution time, design complexity, etc.)
* Then (or concurrently) simplify the design: use an array of array
instead of an ad hoc type list.
* The '''dynamic''' access(es) to the set of
''n''-faces of a complex
(e.g., `mln::complex::nfaces(unsigned)`) has (have) a linear complexity!
We should get rid of that. We could create an index at the creation of
the complex, mapping dynamic dimension numbers to the corresponding
(static) mixin/data.
New description:
See source:branches/cleanup-2008/milena/mln/topo/complex.hh
* Store only the indices ('''and the sign'''!) of adjacent faces
in
`complex_data<D>`: we don't really need actual faces there, and it costs a
lot (memory, execution time, design complexity, etc.)
* Then (or concurrently) simplify the design: use an array of array
instead of an ad hoc type list.
* The '''dynamic''' access(es) to the set of
''n''-faces of a complex
(e.g., `mln::complex::nfaces(unsigned)`) has (have) a linear complexity!
We should get rid of that. We could create an index at the creation of
the complex, mapping dynamic dimension numbers to the corresponding
(static) mixin/data.
Comment (by levill_r):
Update.
--
Ticket URL: <https://trac.lrde.org/olena/ticket/168#comment:1>
Olena <http://olena.lrde.epita.fr>
Olena, a generic and efficient C++ image processing library.