Timeseries models derived from generative graph

[juanitorduz]

As discussed with @ricardoV94 I will port the gist https://gist.github.com/ricardoV94/a49b2cc1cf0f32a5f6dc31d6856ccb63#file-pymc_timeseries_ma-ipynb into the PyMC Example Gallery. I will add text and explanation to the existing working code :)

---

📚 Documentation preview 📚: https://pymc-examples--642.org.readthedocs.build/en/642/

[juanitorduz]

Added!

---

View entire conversation on ReviewNB

[juanitorduz]

yes!

---

View entire conversation on ReviewNB

[juanitorduz]

yes!

---

View entire conversation on ReviewNB

[juanitorduz]

I think as the conditional step has n_steps=trials - lags and the forecasting model has a generic n_steps=forecast_steps it is not that straightforward right?

---

View entire conversation on ReviewNB

[juanitorduz]

Any suggested values ? Changing the seed does not change that much and the rho values go very close to zero many times :D

---

View entire conversation on ReviewNB

[juanitorduz]

@OriolAbril, I am able to add links to the classes, but the functions and methods won't work for some reason ... do you have any tip :)

Concretely, {meth}`~pymc.model.transform.conditioning.observe` does not work (also tried with the scan function in PyTernsor)

[ricardoV94]

I don't know if this can be recovered, but perhaps worth a shot? https://colab.research.google.com/drive/1yLrxTBRPa08B8EIEh6NGWG_aLFxIbanh?usp=sharing

---

View entire conversation on ReviewNB

[ricardoV94]

Does that matter? n_steps can also be a Data variable that you change?

---

View entire conversation on ReviewNB

[jessegrabowski]

You could pick parameters that are 1) strongly persistent, and 2) give imaginary eigenvalues and generate oscillating trajectories. For example, rho_1 = 0.99, rho_2 = -0.99/4

---

View entire conversation on ReviewNB

[OriolAbril]

@juanitorduz These seem particular problems.

---

pytensor.scan is explicitly not indexed within the pytensor docs as a function: https://github.com/pymc-devs/pytensor/blob/main/doc/library/scan.rst?plain=1#L679. My guess from a quick look at the blame is theano probably had any type references which attempt to automatically resolve to any of the possible types, but pytensor.scan is both a module and a function in theano/aesara/pytensor and it seems in aesara times :noindex: was added in multiple places to get those to "work" again.

It looks like the main alternative right now is using {mod}`pytensor.scan` (which is the indexed entry for pytensor.scan). Another option could be keeping func and fixing it on pytensor end, or using the ref type cross-reference to the top of the page, that is ` {ref}scan `

---

For pymc.model.transform.conditioning.observe there doesn't seem to be anything remotely close to that in the pymc docs: https://www.pymc.io/projects/docs/en/latest/api/model.html. If I do look at the source though, I do see a model/conditioning entry which doesn't exist within that folder: https://github.com/pymc-devs/pymc/tree/main/docs/source/api/model, and the transform file is missing, so my guess is it was renamed but the toctree entry not updated, so it is not part of the website navigation tree anymore.

Here you should leave the reference correctly added and then it needs to be fixed on pymc end (once that is done, regenerating the examples will fix the issue without any extra work). Regarding fixing on the pymc docs, do we really expect users to use pymc.model.transform.conditioning.observe when they import observe?

If not, use the actual import path in the reference, and when fixing it document it where the users are expected to import it from (in this case pymc.observe as it is done in the notebook itself), the file structure of the library is completely irrelevant to users and should have no place in the public API docs.

If yes, then the notebook would need to be updated to use that.

[juanitorduz]

Thank you very much @OriolAbril ! (and apologies for the late reply, these last two weeks have been hectic 🫠)