Demo op count reduction if assume sqrt_info is ut

[bradley-solliday-skydio]

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:

• Come up with a mechanism to specify that our sqrt_information matrices
  have specific shapes so that this can be used during codegen
• Pull the sqrt_info matrix out of the residual and instead multiply the
  outputs of the residual function after evaluation.

Topic: demo_sqrt_info_savings
Labels: draft

[bradley-solliday-skydio]

Reviews in this chain:
└#282 Demo op count reduction if assume sqrt_info is ut

[bradley-solliday-skydio]

#	head	base	diff	date	summary
0	87267eb7	1c44a943	diff	Dec 21 19:22 PM	15 files changed, 5560 insertions(+), 6282 deletions(-)

[aaron-skydio]

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.

[bradley-solliday-skydio]

This issue is being tackled by #294