Re: No Observations at the first time step

[DanWaxman]

There was a decision at some point to not allow observations at the first time step (or, at least, not use them). Some explanation of this is part of #189, and it seems to have happened in #191. This is a bit unfortunate for me, as in dynestyx we're trying to have support for multiple different inference backends (including cuthbert), and this assumption is at odds with other libraries (e.g., dynamax).

This makes for some pretty ugly integration code, where I'll have to use some degenerate dynamics for the first time step, re-index any controls and time-variant functions, run the filter, then again re-index at the last step. This is by no means insurmountable, but is somewhat annoying -- it adds like a half hour of dev time to write + document + test, and becomes code that's a bit complicated to explain to other people later on (and easy to mess up if anyone edits it).

From my perspective, it would be much more convenient if this were handled at the filter API level -- e.g., adding a consume_first_observation that uses the first observation if True and ignores it otherwise. c.f. this commit in my fork that I'm currently using for dynestyx.

In general, this isn't a huge deal of course, since this API choice is without loss of generality. But it is a problem that I imagine people will have more than once, and seems worth closing that gap -- even if that just means a nicely-documented example in the docs or some utility function that does this re-indexing for you...

[SamDuffield]

The reason we changed to no initial observation is that for factorial models init_prepare acts on all factors whereas filtering acts locally on only a subset of factors (e.g. 2). This meant that the observation with nans trick resulted in shape mismatches during tracing. You can see my draft branch for factorial model support here #178

There are a couple of other reasons in mind why no initial observation is preferable, (i) it results in less cuthbert code since now all observation code lives in filter_prepare and filter_combine and not also in init_prepare, (ii) predict steps tend to me cheaper than update steps so if we have to do one as a no-op it's preferable for it to be predict. But these aren't deal breakers.

@AdrienCorenflos rules out having such a consume_first_observation and I tend to agree. Although the bool arg might not hard to add, we don't want to set a precedent and supporting both everywhere downstream later might be annoying.

a nicely-documented example in the docs

For sure we need this better documented. #189 will help but an example would also make sense (can be dedicated specifically to having an initial obs)

some utility function that does this re-indexing for you

Agree if we can do this without assuming any structure about model_inputs that would be fantastic (perhaps a big if).

In general, it seems many users will want to have an initial observation and I acknowledge the awkwardness of it currently in cuthbert. So we should work to reduce that awkwardness.