Conversation
| - Home: index.md | ||
| - Quick Start: quickstart.md | ||
| - Quickstart: quickstart.md | ||
| - cuthbert conventions: conventions.md |
There was a problem hiding this comment.
Taking your headings, I think I would create a new docs subsection called "Under the hood" or "Backend" or something like that with the following
- Under the hood
- What cuthbert does and does not do
- Backend design
- Conventions: conventions.md
- Parallel filterI would focus on the why it was designed like this and not other ways.
What cuthbert does and does not do: basically explain cuthbert does inner loop (list current methods, future methods and possibly a roadmap for the library), not parameter estimation outer loop.
Conventions can contain: No initial observation, Square root covariance matrices
Backend design can contain:
- Overview of the design/Unified interfact:
Filter,Smoother(common) andbuild_filter(the part that is different between inference algorithms). My notes from someone fresh to the project may be helpful documentation: explain the backend design #217 - No predict and update. This is what's in the textbook, but we don't do it because we want to make an affine map from
$m_{t+1|t+1} = A m_{t|t} + b$ so that parallel inference is easier (I think that's why). And then some notes onprepareandcombineand how they work, with nuances for each method (noop for SMC?) - Degenerate dynamics
Parallel filter can explain how the associative scan gets a speedup. Feel free to just copy / edit my notes that I wrote here #217 (comment)
There was a problem hiding this comment.
Definitely agree on the why it was designed like this and not other ways !
I'm currently mainly concerned that it's a bit dense and unreadable lol. Splitting it up should help with that!
| Similarly an `update` step can be achieved through degenerate dynamics | ||
| i.e. $p(x_t \mid x_{t-1}) = \delta(x_t \mid x_{t-1})$. | ||
|
|
||
| All `cuthbert` methods support these degenerate cases through appropriate specification |
There was a problem hiding this comment.
Maybe I'm unfamiliar with the context. Why would a user want to do predict and update steps? When would they not just want the full filter step?
There was a problem hiding this comment.
Main one that comes to mind is online inference when they wanted to make decisions based on predict before observing the data
2 participants
Closes #189
It's possible this page would also have sufficient detail to close #217 but that's up for discussion - we could also have an "explain the backend design" page
I've drafted the first few conventions and left placeholders for the remaining ones listed in #189
Very open to help filling those out, suggestions on more to add and suggestions to make it a bit easier to read - more code? tables? figures?