[Work Log] Discussion: maintaining attachment during sampling

September 24, 2013
Project Tulips
Subproject Data Association v3
Working path projects/​tulips/​trunk/​src/​matlab/​data_association_3
SVN Revision 15229
Unless otherwise noted, all filesystem paths are relative to the "Working path" named above.

Struggling with re-assigning associations.

Yesterday, I was planning to re-sample attachments after every change to association. The bookkeeping necessary to ensure reversibility of this is proving to be a nightmare, and it's questionable whether it actually improves results. The counter-argument is that MH moves should be cheap to propose, but re-sampling attachments has significant cost. All that cost is wasted if the proposed move is a bad one, which it often will be. Also, most curves only change slightly when association changes, so changing the branching is probably a bad idea.

Two special cases need to be handled. First is when a change to association causes a curve to become shorter, and an attachment point disappears. In this case, we allow it, but during evaluation, clamp to the endpoint.

However, when birth/death occurs, re-doing attachment is absolutely necessary. In this case, we take a simpler apprach than yesterday's strategy: on death, child curves become root curves; on birth, new curve gathers children from root curves. Or alternatively, birth/death is illegal if curve has children.

The preceeding dicusson about avoiding re-attachment is only valid for re-assignment moves. For split/merge moves, we must update attachment. But this is easy too: on merge, child sets are merged; on split, sample A vs. B based on distance.

Approach #2

When re-assigning associations, if it results in a dangling curve, reject

Posted by Kyle Simek
blog comments powered by Disqus