Closed bradley-solliday-skydio closed 1 year ago
Reviews in this chain: └https://github.com/symforce-org/symforce/pull/282 Demo op count reduction if assume sqrt_info is ut
We should be able to generate all our builtin residuals with different sqrt_info shapes (none, isotropic, diagonal, full) and the same function name, and leave it to C++ overload resolution? That seems like a good idea and should be really easy to do. Only case that doesn't cover is triangular, e.g. if you get it from a cholesky decomposition as you mention :)
I think that case is probably specific enough that it's fine to say you should generate your own factor for those cases, or if e.g. for IMU preintegration that's always the case then the one factor we generate for that would assume/require the sqrt info is triangular.
This might also be worth calling out in a tutorial, or "performance tips" section of the docs.
This issue is being tackled by https://github.com/symforce-org/symforce/pull/294
In many of our generated factors, we take the square root information matrix as an argument, but make no assumptions about it's sparsity pattern, assuming it's just a regular dense square matrix.
However, often times we pass in special matrices, for example diagonal matrices or upper triangular matrices (which one might get if one uses cholesky decomposition on the inverse of the covariance, for example).
As this commit demonstrates, passing this knowledge on to the symbolic implementation of the code can reduce op counts considerably.
So, if we care about reducing op counts in these cases, a couple options come to mind:
Topic: demo_sqrt_info_savings Labels: draft