#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