[Work Log] Attachment ML Math (ctd); Implementing Attach()/Detach()

August 22, 2013

Project	Tulips
Subproject	Data Association v3
Working path	projects/tulips/trunk/src/matlab/data_association_3
SVN Revision	15169

Unless otherwise noted, all filesystem paths are relative to the "Working path" named above.

Note new working path: data_association_3
Fixed corrupt svn working copy.

Computing \(\mu_b\) and \(\Sigma_b\)

Since \(S\) is usually singular, we can't invert it, so we need to tweak yesterday's equations. In what follows, the precision matrix \(S\) is decomposed into \(s s^\top\), which will allow us to keep the covariance matrix symmetric.

The updated forumula for \(\mu_b\) is:

\[ \begin{align} \mu_b &= K_*^\top \left(K_{\mathcal{MB}} + S^{-1}\right)^{-1} y_{MB} \\ \tag{1} &= K_*^\top s^\top \left(s K_{\mathcal{MB}} s^\top + I\right)^{-1} s y_{MB} \\ \end{align} \] The formula for \(\Sigma_b\) is: \[ \Sigma_b = K_b - K_*^\top s^\top \left(s K_{\mathcal{MB}} s^\top + I\right)^{-1} s K_* \] Recall that \(K_b\) is the prior covariance of the branch point.

Predictive covariance question

I realized during implementation that it isn't clear what the predictive covariance, \(K_*\), should be. I know it's the covariance between the true branch point and the observed points in the markov blanket, but the observed points have associated view-indices, while the branch point does not. After some thought, I realized that the covariance arising from view-indices is essentially *likelihood* variance in this context (i.e. imaging noise), and according to Williams and Rasmussen, these parts of the likelihood should be omitted when computing the covariance between data and true unobserved points. (See equation (2.21), notice that off-diagonal elements don't include the noise variance, \(\sigma_n I\)).

To accomodate the use-case where you want to compute the covariance while ignoring view-index, I tweaked `kernel/get_model_kernel`; now, if you pass-in a `model_index` of zero, it returns a two-parameter no-perturb kernel where only spacial-indices are received.

`ll_indices_flat` vs. `prior_indices`

There's some ambiguity in these two fields of a curve-track. The difference is simply that in ll_indices_flat, indices always start at zero, whereas in prior_indices the offset start_index is added to all values. In practice, there are rules for where these two fields should be used:

when passing indices to a kernel, always use prior_indices
When dealing with geometry (e.g. referring to a point along a curve), always use ll_indices. That way, the position of the referred point is unchanged if start_index ever changes.

Task progress

Finish attachment/att_set_branch_index.m.
rough test of attachment stuff - (does it parse? does it run?)
- It runs, but with buggy output for \(\mu_b\) and \(\Sigma_b\).
- Found bug - incorrect re-indexing (xxyyzz to xyzxyz)
- Now giving apparently good results.
Implement efficient tree ML
implement naive ML
write tests
1. compare against curve_ml5.m for independent curves
2. compare against naive ML using full-covariance-matrix.
invalidate children after calling attach/detach

Misc notes

should place a condition on \(\Sigma_b\). If it's variance is too high, need to expand markov-blanket.
Add model_type to params
Have "make_correspondence" initialize start_index, parent_index, branch_index.

chain of affects

How are children affected when properties of the parent change?

parent property	self affects	child affects
Assoc/Correspondence	start_index (and inherited)	Branch_index (and inherited. easy to re-estimate deterministically), marginal likelihood, (not start index)
Start index	prior_K, prior_indices, ML	\(\mu_b\), \(\Sigma_b\), ML*
Branch index	\(\mu_b\), \(\Sigma_b\),	none.

* Updating these might not be necessary

TODO

Implement Tree ML (2 ways, "naive" and "fast")
Test
Get attachment for ground truth
Re-train using attachment

Posted by Kyle Simek

Misc. → ← Clique-tree math (ctd)

KLS Research Blog ← Nothing to see here...