charles-river-analytics / scruff.jl Goto Github PK

The time offset capability was added in merge #50. This task is to update the soccer example using time offset as appropriate.

Gibbs sampling can be implemented relatively easily as a message-passing algorithm.
Metropolis-Hastings requires more thought.

This issue is used to trigger TagBot; feel free to unsubscribe.

If you haven't already, you should update your TagBot.yml to include issue comment triggers.
Please see this post on Discourse for instructions and more details.

If you'd like for me to do this for you, comment TagBot fix on this issue.
I'll open a PR within a few hours, please be patient!

Requires good profiling.

These should have similar flexibility to temporal models.
We will need to define windowed filtering methods for these.
We should also allow graph-structured models.

EM can be implemented using a statistics semiring.
We should get asynchronous online EM out of this.

This SFunc should represent data-driven operations that can use an output to derive a probability distribution over inputs, e.g. like a feedforward neural network. They can implement send_lambda, but not sample or compute_pi. Write algorithms to use them.

Expected utilities can also be computed using a semiring.
We should try to implement limited memory to avoid exponential blowup in the number of decisions.
We need to figure out how to do forward projection asynchronously when we don't know the timing of actions and observations.

It should be possible to say with_semiring(semiring, algorithm) and have the semiring flow down to all the operations.
Should be achievable with policies.

Currently, all dependencies in a HomogeneousModel that are not from the self-parent are from the same time. We want to allow them to be from a previous time.

In order to model external control, we must make interventions work with filtering.

We wish to be able to profile operations, such that we know how long they take, how much memory they use, and how accurate they are.

We should convert all references to Float64 to Real.

Currently we have Expanders, but they were an early development in Scruff and are clunky. It would be better if variables could be associated with NetworkModels, which generate NetworkSFuncs.

Something like this exists already - need to check if it is complete and works as expected, and document it.
Then, if we have higher order SFuncs over NetworkSFuncs, they will subsume Expanders.

Finally, we need to make LazyInference work with any embedded Network/NetworkSFuncs and not just Expanders.
Once all this is done, we can deprecate Expanders.

The longer an algorithm runs, the more instances will be stored in a Runtime instance. In some cases, for long running algorithms, this may cause memory issues. The user should be able to specify a limit, either by count or by time or by memory pressure, for how many instances a Runtime can keep around.

This also applies to projections.

Suggestion: implement via a specialized send_lambda operation on linear Gaussians.

It should be possible to update beliefs about any instances in the window and query them.

Use Distributions.jl API to wrap distributions with operations and enable them to be used by Scruff.

We have some operator signatures with parrange etc. that are not part of the mathematical signature of the operation that is intended. They should be removed and either incorporated into the SFuncs or treated as operation hyperparameters.