17 Jun
2014
17 Jun
'14
2:59 p.m.
#168: Revamp mln::topo::internal::complex_data<D>
--------------------------+----------------------
Reporter: levill_r | Owner: levill_r
Type: enhancement | Status: new
Priority: trivial | Milestone:
Component: Milena | Version: 2.0
Resolution: | Keywords: cleanup
--------------------------+----------------------
Changes (by levill_r):
* priority: major => trivial
* version: 1.0 => 2.0
* milestone: Olena 2.1 =>
Old 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.
New description:
See source: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.
--
--
Ticket URL: <https://trac.lrde.epita.fr/olena/ticket/168#comment:3>
Olena <http://olena.lrde.epita.fr>
Olena, a generic and efficient image processing platform