[Work Log]

Continuing debugging of new likelihood

Test: test/test_ml_end_to_end_2.m

07:11:52 AM

Trouble with NaN error in correspondence/corr_to_likelihood_legacy.m.

08:22:43 AM

Narrowed it down to gap-handling code-branch.

08:53:34 AM

Fixed. Arose from a nasty indexing scheme in the original clean_correspondence.m, which I didn't handle well when adapting for corr_to_likelihood_legacy.m.

09:29:35 AM

Nonsingular prior covariance matrix causing crash. Apparently caused by same index appearing multiple times.

In the past, we always merged such points.

The new idea is different views of the same point would make the posterior covariance singular. Either this isn't true, or there's a bug...

Debugging this will take some serious coding and math brainpower and I fell debugging fatigue coming on. Taking a brief break to refresh, then will tackle...

11:56:21 AM

Using a simple toy example, I (partially) confirmed my intuition that a degenerate prior matrix is okay, as long as its nullspace is spanned by the likelihood matrix.

In the context of this bug, it means that two points sharing the same index value is fine as long as they arose from different views (assuming non-degenerate camera configuration, which is true in this case).

Possible causes

1. Numerical instability -- near-singular matrix.
2. Error in Linear Algebra logic (seems unlikely, same code worked in old likelihood)
3. Some bug earlier in the pipeline, causing invalid matrices here.

I'm guessing its 3; if not that, then maybe 2.

Next steps

• inspect the shared indices -- same view?

12:48:49 PM

Reversing my previous stance: Degenerate prior with shared index will always result in a degenerate posterior. The prior has two variables that are 100% correlated, and the posterior will also be 100% correlated. This implies a degenerate covariance matrix.

In such a case, the posterior's implied dimensionality is lower than it's apparent dimensionality. The prior and posterior will be degenerate in the same way; this symmetry is aesthetically appealing, because the Candidates estimator for the marginal likelihood involves their ratio. This suggests that eliminating the redundant dimensions for both pdfs is a sensible thing to do.

How to resolve this? Possibilities:

1. Detect redundant indices early, eliminate them in the prior and posterior. USe bookkeeping to remember which observations refer to the same model point.
2. Handle reduntancies later, after degenerate posterior is formed, before evaluating posterior or prior . The mean will automatically contain redundancies, which will avoid bookkeeping when comparing the mean to the data points (when mix is != 0).
3. Try to determine how identical indices arose in the first place.

Decided on 2 for now. In retrospect, approach 1 may have had slightly less code and faster.

01:45:00 PM

ML is now running on legacy correspondence. Results are significantly higher than the legacy ML algorithm (~ 2.25 times). Not yet sure why yet.

Computing marginal likelihood (old way)...
Done. (6665.8 ms)
Old ML: 207.041742
Computing marginal likelihood (new way, legacy correspondence)...
Done. (8853.1 ms)
New ML (Legacy corr): 439.273126

Noticible slow-down, probably because of extra indices arising from not merging duplicate observations.

possible causes of discrepancy:

1. In old code, re-triangulation used simple averaging, not accounting for differing precisions of the points
2. index sets differ between old and new code. (update: checked, they are same)

Plotting means for both to view differences...

Investigation into ML discrepancy:

• Posterior means are similar, but obviously differ.
• both means are very non-smooth (need to re-address the smoothness issue)
• new mean has signficantly more points (~7%, 80 pts). Could this alone affect ML?
• almost all difference is in posterior

Maybe posterior kernel is different? but prior is same It's just the data covariance thats different. but why?? There's more of them.

New ml changes significantly when evaluation point changes. This implies that the posterior curvature differs from the curvature of the joint distribution, which shouldn't happen. A small amount of difference can arise naturally due to the approximation of the likelihood, but this is too large to be explained in that way. Most noticibly, the new results look very similar to the old ones when evaluating at the likelihood mean. The largest difference occurs when evaluating at the posterior mean. Not clear yet what conclusions to draw from this, or if this is just a coincidence.

Maybe likelihood curvatures are differing.

07:35:28 PM

Was able to get identical likelihood value using matrix-form as I did with the original 2D geometric error form. Seems like the precision matrices are good.

Priors appear good too, since it evaluates to the same value as the reference implementation.

Reference implementation for new ML

Idea: direct implementation for quadform, but with hacked nomralization constant

In progress

• diagnosing errors in new likelihood curve_ml_3.m.
• getting test_ml_end_to_end_2.m running.

Posted by Kyle Simek

blog comments powered by Disqus