turion / rhine

Haskell Functional Reactive Programming framework with type-level clocks
http://hackage.haskell.org/package/rhine
117 stars 21 forks source link

Time Aware Inference #284

Open reubenharry opened 5 months ago

reubenharry commented 5 months ago

There are situations where we might want our posterior to itself be a signal network or Rhine rather than a Behavior.

  1. Suppose that we have a model that has two variables. Concretely, suppose that the model describes a ball moving in 2D, but the mean of the process describing the ball also varies, but at a much lower timescale. In this case, there are already two clocks in the prior. I don't see how we would currently express this.
  2. Suppose that we want to incorporation observations (using arrM factor) on a different clock also, perhaps an event based clock even.

I had initially thought I could write something like:

genModel :: MonadMeasure m => Rhine
  m
  (SequentialClock (Millisecond 1000) (SequentialClock (Millisecond 10) (Millisecond 100)))
  ()
  Pos
genModel = prior2d @@ (waitClock :: Millisecond 1000 ) >-- keepLast (0,0) -->
    obs @@ (waitClock :: Millisecond 10)  >-- keepLast (0,0) --> (proc pos -> do
        arrM factor -< undefined
        returnA -< pos) @@ (waitClock :: Millisecond 100)

but it became apparent that this requires various typeclass instances that I don't know how to define (and probably can't be?), for ScheduleT and Clock. Moreover, there doesn't seem to be a way to apply a monad morphism to m, to convert it to IO down the road.

However, conceptually it seems like it should be possible to express a model which has asynchronous parts, and also to envision a particle filter running on it. For example, if I have a Sequential signal network (as in the Rhine above), I could run a particle filter by running particles through the sequential parts in some way. Or maybe not.

(btw, if I am cluttering up the issues with discussion issues like this, feel free to close and we can revert to another channel of communication)