User controlled tick rate

[reubenharry]

Sorry if this is a simple question, but I would like to run a rhine on a clock that has a varying tick rate, which the user can control. So, more concretely, I would like the user to be able to input a tick rate at any point during a simulation (e.g. using a widget in gloss, or via the command line) and for the process to subsequently tick at that rate.

Is this within the remit of Rhine?

(Context: I'm using Rhine to implement numerical integration schemes, and it's nice to visualize in gloss how the step size affects the dynamics. But if I change the step size in the naive way, it will speed up or slow down the visualization, so it seems that really I want to change the clock's tick rate)

[turion]

That's a simple but great question! The answer is yes, this should be easily possible. I'd solve this by using a monad to communicate the clock rate to the clock. Something like this:

data VaryingClock = VaryingClock

defaultRate :: Double
defaultRate = 0.1

instance (MonadAccum (Last Double) m, MonadIO m) => Clock m VaryingClock where
  type Time VaryingClock = Double
  type Tag VaryingClock = ()
  initClock _ = return ((constM look >>> arr (getLast >>> fromMaybe defaultRate) >>> sumN) &&& arr (const ()), 0)

setRate :: MonadAccum (Last Double) m => ClSF m cl Double ()
setRate = arrM $ add . Last . Just

This uses the Accum monad to read the last set clock rate. (We can't use StateT because that doesn't have a MonadSchedule instance - state in all generality is by definition single threaded. AccumT does have a MonadSchedule instance with an "eventually-consistent" concurrency semantics.)

This clock is completely pure, but you can give it real time semantics by using e.g. https://hackage.haskell.org/package/rhine-1.5/docs/FRP-Rhine-Clock-Realtime.html#t:WaitUTCClock

[reubenharry]

Thank you so much, this is exactly what I needed!

Once I have clean examples running, I'll share them. Basically, I'm representing discretized ODEs (or in fact SDEs - I can use Rhine-Bayes after all) as a signal function. Then a clock, such as the above, determines the discretization rate (which need not be constant). More specifically, I'm using this to visualize sampling algorithms like Hamiltonian Monte Carlo, which runs an ODE that evolves particles to a stationary distribution.

[turion]

That sounds like a perfect application!