[Olena] #160: Revamp complexes
#160: Revamp complexes ----------------------------+----------------------------------------------- Reporter: levill_r | Owner: Olena Team Type: enhancement | Status: new Priority: minor | Milestone: Olena 1.0 Component: Milena | Version: 1.0 Keywords: cleanup rename | ----------------------------+----------------------------------------------- * Move complexes from `mln/core/` to `mln/topo/`. * 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. Ask Roland for details. -- Ticket URL: <https://trac.lrde.org/olena/ticket/160> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image processing library.
#160: Revamp complexes (and faces) --------------------------+------------------------------------------------- Reporter: levill_r | Owner: Olena Team Type: enhancement | Status: new Priority: minor | Milestone: Olena 1.0 Component: Milena | Version: 1.0 Resolution: | Keywords: cleanup rename --------------------------+------------------------------------------------- Changes (by levill_r): * summary: Revamp complexes => Revamp complexes (and faces) Old description:
* Move complexes from `mln/core/` to `mln/topo/`. * 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. Ask Roland for details.
New description: * Move complexes from `mln/core/` to `mln/topo/`. * 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. Ask Roland for details. * From source:trunk/milena/mln/core/face.hh: {{{ /* FIXME: Suggestions: - rename `face' as `face_data', and move it into complex.hh or its own file; - rename `face_handle' as `face', and move it to its own file; - rename `any_face_handle' as `any_face', and move it to its own file. Anyway, whatever the decision, splitting `face', `face_handle' and `any_face_handle' seems to be sound. (And what about `faces_set'? Should we move it to its own file as well?) */ }}} Comment: Record more work (on faces). -- Ticket URL: <https://trac.lrde.org/olena/ticket/160#comment:1> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image processing library.
#160: Revamp complexes (and faces) --------------------------+------------------------------------------------- Reporter: levill_r | Owner: Olena Team Type: enhancement | Status: new Priority: minor | Milestone: Olena 1.0 Component: Milena | Version: 1.0 Resolution: | Keywords: cleanup rename --------------------------+------------------------------------------------- Old description:
* Move complexes from `mln/core/` to `mln/topo/`. * 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. Ask Roland for details. * From source:trunk/milena/mln/core/face.hh: {{{ /* FIXME: Suggestions:
- rename `face' as `face_data', and move it into complex.hh or its own file; - rename `face_handle' as `face', and move it to its own file; - rename `any_face_handle' as `any_face', and move it to its own file.
Anyway, whatever the decision, splitting `face', `face_handle' and `any_face_handle' seems to be sound.
(And what about `faces_set'? Should we move it to its own file as well?) */ }}}
New description: * Move complexes from `mln/core/` to `mln/topo/`. * 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. Ask Roland for details. * From source:trunk/milena/mln/core/face.hh: {{{ /* FIXME: Suggestions: - rename `face' as `face_data', and move it into complex.hh or its own file; - rename `face_handle' as `face', and move it to its own file; - rename `any_face_handle' as `any_face', and move it to its own file. Anyway, whatever the decision, splitting `face', `face_handle' and `any_face_handle' seems to be sound. (And what about `faces_set'? Should we move it to its own file as well?) */ }}} * Fix constness problems w.r.t. complexes and face handles (faces handles require a mutable pointer to their complex for construction reasons). Comment (by levill_r): Report constness issues. -- Ticket URL: <https://trac.lrde.org/olena/ticket/160#comment:2> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image processing library.
#160: Revamp complexes (and faces) --------------------------+------------------------------------------------- Reporter: levill_r | Owner: levill_r Type: enhancement | Status: assigned Priority: minor | Milestone: Olena 1.0 Component: Milena | Version: 1.0 Resolution: | Keywords: cleanup rename --------------------------+------------------------------------------------- Changes (by levill_r): * status: new => assigned * owner: Olena Team => levill_r Old description:
* Move complexes from `mln/core/` to `mln/topo/`. * 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. Ask Roland for details. * From source:trunk/milena/mln/core/face.hh: {{{ /* FIXME: Suggestions:
- rename `face' as `face_data', and move it into complex.hh or its own file; - rename `face_handle' as `face', and move it to its own file; - rename `any_face_handle' as `any_face', and move it to its own file.
Anyway, whatever the decision, splitting `face', `face_handle' and `any_face_handle' seems to be sound.
(And what about `faces_set'? Should we move it to its own file as well?) */ }}} * Fix constness problems w.r.t. complexes and face handles (faces handles require a mutable pointer to their complex for construction reasons).
New description: * ~~Move complexes from `mln/core/` to `mln/topo/`.~~ (Done in r2377 and r2380.) * 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. Ask Roland for details. * From source:trunk/milena/mln/core/face.hh: {{{ /* FIXME: Suggestions: - rename `face' as `face_data', and move it into complex.hh or its own file; - rename `face_handle' as `face', and move it to its own file; - rename `any_face_handle' as `any_face', and move it to its own file. Anyway, whatever the decision, splitting `face', `face_handle' and `any_face_handle' seems to be sound. (And what about `faces_set'? Should we move it to its own file as well?) */ }}} * Fix constness problems w.r.t. complexes and face handles (faces handles require a mutable pointer to their complex for construction reasons). Comment: Update the to-do list. -- Ticket URL: <https://trac.lrde.org/olena/ticket/160#comment:3> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image processing library.
#160: Revamp complexes (and faces) --------------------------+------------------------------------------------- Reporter: levill_r | Owner: levill_r Type: enhancement | Status: assigned Priority: minor | Milestone: Olena 1.0 Component: Milena | Version: 1.0 Resolution: | Keywords: cleanup rename --------------------------+------------------------------------------------- Old description:
* ~~Move complexes from `mln/core/` to `mln/topo/`.~~ (Done in r2377 and r2380.) * 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. Ask Roland for details. * From source:trunk/milena/mln/core/face.hh: {{{ /* FIXME: Suggestions:
- rename `face' as `face_data', and move it into complex.hh or its own file; - rename `face_handle' as `face', and move it to its own file; - rename `any_face_handle' as `any_face', and move it to its own file.
Anyway, whatever the decision, splitting `face', `face_handle' and `any_face_handle' seems to be sound.
(And what about `faces_set'? Should we move it to its own file as well?) */ }}} * Fix constness problems w.r.t. complexes and face handles (faces handles require a mutable pointer to their complex for construction reasons).
New description: * ~~Move complexes from `mln/core/` to `mln/topo/`.~~ (Done in r2399, r2400 and r2401.) * 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. Ask Roland for details. * From source:branches/cleanup-2008/milena/mln/topo/face.hh: {{{ /* FIXME: Suggestions: - rename `face' as `face_data', and move it into complex.hh or its own file; - rename `face_handle' as `face', and move it to its own file; - rename `any_face_handle' as `any_face', and move it to its own file. Anyway, whatever the decision, splitting `face', `face_handle' and `any_face_handle' seems to be sound. (And what about `faces_set'? Should we move it to its own file as well?) */ }}} * Fix constness problems w.r.t. complexes and face handles (faces handles require a mutable pointer to their complex for construction reasons). Comment (by levill_r): Fix the previous change and update paths. -- Ticket URL: <https://trac.lrde.org/olena/ticket/160#comment:4> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image processing library.
#160: Revamp complexes (and faces) --------------------------+------------------------------------------------- Reporter: levill_r | Owner: levill_r Type: enhancement | Status: assigned Priority: minor | Milestone: Olena 1.0 Component: Milena | Version: 1.0 Resolution: | Keywords: cleanup rename --------------------------+------------------------------------------------- Old description:
* ~~Move complexes from `mln/core/` to `mln/topo/`.~~ (Done in r2399, r2400 and r2401.) * 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. Ask Roland for details. * From source:branches/cleanup-2008/milena/mln/topo/face.hh: {{{ /* FIXME: Suggestions:
- rename `face' as `face_data', and move it into complex.hh or its own file; - rename `face_handle' as `face', and move it to its own file; - rename `any_face_handle' as `any_face', and move it to its own file.
Anyway, whatever the decision, splitting `face', `face_handle' and `any_face_handle' seems to be sound.
(And what about `faces_set'? Should we move it to its own file as well?) */ }}} * Fix constness problems w.r.t. complexes and face handles (faces handles require a mutable pointer to their complex for construction reasons).
New description: * ~~Move complexes from `mln/core/` to `mln/topo/`.~~ (Done in r2399, r2400 and r2401.) * 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. Ask Roland for details. * ~~Suggestions from source:branches/cleanup-2008/milena/mln/topo/face.hh:2399~~. (Done in r2412, r2413, r2414, r2415 and r2416). * Fix constness problems w.r.t. complexes and face handles (faces handles require a mutable pointer to their complex for construction reasons). Comment (by levill_r): Update the to-do list. -- Ticket URL: <https://trac.lrde.org/olena/ticket/160#comment:5> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image processing library.
#160: Revamp complexes (and faces) --------------------------+------------------------------------------------- Reporter: levill_r | Owner: levill_r Type: enhancement | Status: assigned Priority: minor | Milestone: Olena 1.0 Component: Milena | Version: 1.0 Resolution: | Keywords: cleanup rename --------------------------+------------------------------------------------- Old description:
* ~~Move complexes from `mln/core/` to `mln/topo/`.~~ (Done in r2399, r2400 and r2401.) * 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. Ask Roland for details. * ~~Suggestions from source:branches/cleanup-2008/milena/mln/topo/face.hh:2399~~. (Done in r2412, r2413, r2414, r2415 and r2416). * Fix constness problems w.r.t. complexes and face handles (faces handles require a mutable pointer to their complex for construction reasons).
New description: * ~~Move complexes from `mln/core/` to `mln/topo/`.~~ (Done in r2399, r2400 and r2401.) * ~~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. Ask Roland for details.~~ (Moved to #168.) * ~~Suggestions from source:branches/cleanup-2008/milena/mln/topo/face.hh:2399~~. (Done in r2412, r2413, r2414, r2415 and r2416). * Fix constness problems w.r.t. complexes and face handles (faces handles require a mutable pointer to their complex for construction reasons). Comment (by levill_r): Move an item to #168. -- Ticket URL: <https://trac.lrde.org/olena/ticket/160#comment:6> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image processing library.
#160: Revamp complexes (and faces) --------------------------+------------------------------------------------- Reporter: levill_r | Owner: levill_r Type: enhancement | Status: assigned Priority: minor | Milestone: Olena 1.0 Component: Milena | Version: 1.0 Resolution: | Keywords: cleanup rename --------------------------+------------------------------------------------- Old description:
* ~~Move complexes from `mln/core/` to `mln/topo/`.~~ (Done in r2399, r2400 and r2401.) * ~~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. Ask Roland for details.~~ (Moved to #168.) * ~~Suggestions from source:branches/cleanup-2008/milena/mln/topo/face.hh:2399~~. (Done in r2412, r2413, r2414, r2415 and r2416). * Fix constness problems w.r.t. complexes and face handles (faces handles require a mutable pointer to their complex for construction reasons).
New description: * ~~Move complexes from `mln/core/` to `mln/topo/`.~~ (Done in r2399, r2400 and r2401.) * ~~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. Ask Roland for details.~~ (Moved to #168.) * ~~Suggestions from source:branches/cleanup-2008/milena/mln/topo/face.hh:2399~~. (Done in r2412, r2413, r2414, r2415 and r2416). * Fix constness problems w.r.t. complexes and face handles (faces handles require a mutable pointer to their complex for construction reasons). * Rename `face_id` (and its accessors) as `id`? Comment (by levill_r): Add a suggestion of renaming. -- Ticket URL: <https://trac.lrde.org/olena/ticket/160#comment:7> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image processing library.
#160: Revamp complexes (and faces) --------------------------+------------------------------------------------- Reporter: levill_r | Owner: levill_r Type: enhancement | Status: assigned Priority: minor | Milestone: Olena 1.0 Component: Milena | Version: 1.0 Resolution: | Keywords: cleanup rename --------------------------+------------------------------------------------- Old description:
* ~~Move complexes from `mln/core/` to `mln/topo/`.~~ (Done in r2399, r2400 and r2401.) * ~~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. Ask Roland for details.~~ (Moved to #168.) * ~~Suggestions from source:branches/cleanup-2008/milena/mln/topo/face.hh:2399~~. (Done in r2412, r2413, r2414, r2415 and r2416). * Fix constness problems w.r.t. complexes and face handles (faces handles require a mutable pointer to their complex for construction reasons). * Rename `face_id` (and its accessors) as `id`?
New description: * ~~Move complexes from `mln/core/` to `mln/topo/`.~~ (Done in r2399, r2400 and r2401.) * ~~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. Ask Roland for details.~~ (Moved to #168.) * ~~Suggestions from source:branches/cleanup-2008/milena/mln/topo/face.hh:2399~~. (Done in r2412, r2413, r2414, r2415 and r2416). * Fix constness problems w.r.t. complexes and face handles (faces handles require a mutable pointer to their complex for construction reasons). * Rename `face_id` (and its accessors) as `id`? * Factor redundant code in source:branches/cleanup-2008/milena/tests/topo/complex.cc Comment (by levill_r): More work. -- Ticket URL: <https://trac.lrde.org/olena/ticket/160#comment:8> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image processing library.
#160: Revamp complexes (and faces) --------------------------+------------------------------------------------- Reporter: levill_r | Owner: levill_r Type: enhancement | Status: assigned Priority: minor | Milestone: Olena 1.0 Component: Milena | Version: 1.0 Resolution: | Keywords: cleanup rename --------------------------+------------------------------------------------- Old description:
* ~~Move complexes from `mln/core/` to `mln/topo/`.~~ (Done in r2399, r2400 and r2401.) * ~~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. Ask Roland for details.~~ (Moved to #168.) * ~~Suggestions from source:branches/cleanup-2008/milena/mln/topo/face.hh:2399~~. (Done in r2412, r2413, r2414, r2415 and r2416). * Fix constness problems w.r.t. complexes and face handles (faces handles require a mutable pointer to their complex for construction reasons). * Rename `face_id` (and its accessors) as `id`?
* Factor redundant code in source:branches/cleanup-2008/milena/tests/topo/complex.cc
New description: * ~~Move complexes from `mln/core/` to `mln/topo/`.~~ (Done in r2399, r2400 and r2401.) * ~~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. Ask Roland for details.~~ (Moved to #168.) * ~~Suggestions from source:branches/cleanup-2008/milena/mln/topo/face.hh:2399~~. (Done in r2412, r2413, r2414, r2415 and r2416). * Fix constness problems w.r.t. complexes and face handles (faces handles require a mutable pointer to their complex for construction reasons). * Rename `n` (and its accessors) as `dim`? * Rename `face_id` (and its accessors) as `id`? * Factor redundant code in source:branches/cleanup-2008/milena/tests/topo/complex.cc Comment (by levill_r): More suggestions. -- Ticket URL: <https://trac.lrde.org/olena/ticket/160#comment:9> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image processing library.
#160: Revamp complexes (and faces) --------------------------+------------------------------------------------- Reporter: levill_r | Owner: levill_r Type: enhancement | Status: assigned Priority: minor | Milestone: Olena 1.0 Component: Milena | Version: 1.0 Resolution: | Keywords: cleanup rename --------------------------+------------------------------------------------- Old description:
* ~~Move complexes from `mln/core/` to `mln/topo/`.~~ (Done in r2399, r2400 and r2401.) * ~~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. Ask Roland for details.~~ (Moved to #168.) * ~~Suggestions from source:branches/cleanup-2008/milena/mln/topo/face.hh:2399~~. (Done in r2412, r2413, r2414, r2415 and r2416). * Fix constness problems w.r.t. complexes and face handles (faces handles require a mutable pointer to their complex for construction reasons). * Rename `n` (and its accessors) as `dim`? * Rename `face_id` (and its accessors) as `id`?
* Factor redundant code in source:branches/cleanup-2008/milena/tests/topo/complex.cc
New description: * ~~Move complexes from `mln/core/` to `mln/topo/`.~~ (Done in r2399, r2400 and r2401.) * ~~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. Ask Roland for details.~~ (Moved to #168.) * ~~Suggestions from source:branches/cleanup-2008/milena/mln/topo/face.hh:2399~~. (Done in r2412, r2413, r2414, r2415 and r2416). * Fix constness problems w.r.t. complexes and face handles (faces handles require a mutable pointer to their complex for construction reasons). * Rename `n` (and its accessors) as `dim`? * Rename `face_id` (and its accessors) as `id`? * Rename `algebraic_face` (resp. `algebraic_n_face`) as `oriented_face` (resp. `oriented_n_face`)? * Factor redundant code in source:branches/cleanup-2008/milena/tests/topo/complex.cc Comment (by levill_r): More renaming proposals. -- Ticket URL: <https://trac.lrde.org/olena/ticket/160#comment:10> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image processing library.
#160: Revamp complexes (and faces) --------------------------+------------------------------------------------- Reporter: levill_r | Owner: levill_r Type: enhancement | Status: assigned Priority: minor | Milestone: Olena 1.1 Component: Milena | Version: 1.0 Resolution: | Keywords: cleanup rename --------------------------+------------------------------------------------- Changes (by levill_r): * milestone: Olena 1.0 => Olena 1.1 Comment: As this is not critical for the release of Olena 1.0, move this into milestone:"Olena 1.1". -- Ticket URL: <https://trac.lrde.org/olena/ticket/160#comment:11> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image processing library.
#160: Revamp complexes (and faces) --------------------------+---------------------------- Reporter: levill_r | Owner: levill_r Type: enhancement | Status: closed Priority: minor | Milestone: Olena 2.1 Component: Milena | Version: 2.0 Resolution: fixed | Keywords: cleanup rename --------------------------+---------------------------- Changes (by levill_r): * status: assigned => closed * version: 1.0 => 2.0 * resolution: => fixed Comment: Mostly complete; other potential changes probably deserve their own tickets; closing. -- Ticket URL: <https://trac.lrde.epita.fr/olena/ticket/160#comment:12> Olena <http://olena.lrde.epita.fr> Olena, a software platform dedicated to image processing.
participants (2)
-
Olena -
Olena Trac