FRP, Simulations and Time (Sodium et. al)

FPR is usually described as a way to model interactions with the real world. I believe the same ideas should be applicable to simulations. Instead of "real" events I would use fake events. This however only makes sense when the Time associated with the Events (and Behaviors) is not wallclock time, but some kind of virtual time. I looked briefly into Sodium and found no way to use "my own time". Steven Blackheath even said during a presentation, that Time in Sodium is just another Behavior. I am not sure if I understood this correctly, but it gives me the feeling, that the only Time available in Sodium is wallclock time, which would make it unsuitable for simulations. Could someone give me some insights whether or not FRP is suitable for simulations? Does my reasoning about Time make any sense? Do different libraries treat Time in different ways, such that some are suitable for simulations, while others are not? Martin

Look up hydra and related tools. Simulation modeling tools are a bit
different. There's also fewer public examplds, though I hope to change
that soon.
On Sunday, March 16, 2014, martin
FPR is usually described as a way to model interactions with the real world. I believe the same ideas should be applicable to simulations. Instead of "real" events I would use fake events. This however only makes sense when the Time associated with the Events (and Behaviors) is not wallclock time, but some kind of virtual time.
I looked briefly into Sodium and found no way to use "my own time". Steven Blackheath even said during a presentation, that Time in Sodium is just another Behavior. I am not sure if I understood this correctly, but it gives me the feeling, that the only Time available in Sodium is wallclock time, which would make it unsuitable for simulations.
Could someone give me some insights whether or not FRP is suitable for simulations?
Does my reasoning about Time make any sense? Do different libraries treat Time in different ways, such that some are suitable for simulations, while others are not?
Martin
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org javascript:; http://www.haskell.org/mailman/listinfo/haskell-cafe

Martin,
It depends on that how FRP is defined.
So, in F# it is usually associated with the Async monad and IObservable
interface.
If we will follow in the same direction then the short answer is definitely
yes. An example is my simulation library Aivika [1].
My Process monad allows describing the discontinuous processes (inspired by
the Async monad from F#). There is also the Signal type (inspired by the
.NET IObservable interface) that allows notifying about some (.NET-like)
events such as an update of the variable.
Then the characteristic function in a context of FRP would be the next one:
processAwait :: Signal a -> Process a
There is an opposite direction from the Process computation to signals
through the Task type but it is a little bit complicated as the
discontinuous process can be canceled, or an IO exception may arise within
the computation.
But the simulation field is too big and diverse to assert something general.
Thanks,
David
[1] http://hackage.haskell.org/package/aivika
On Sun, Mar 16, 2014 at 5:23 PM, martin
FPR is usually described as a way to model interactions with the real world. I believe the same ideas should be applicable to simulations. Instead of "real" events I would use fake events. This however only makes sense when the Time associated with the Events (and Behaviors) is not wallclock time, but some kind of virtual time.
I looked briefly into Sodium and found no way to use "my own time". Steven Blackheath even said during a presentation, that Time in Sodium is just another Behavior. I am not sure if I understood this correctly, but it gives me the feeling, that the only Time available in Sodium is wallclock time, which would make it unsuitable for simulations.
Could someone give me some insights whether or not FRP is suitable for simulations?
Does my reasoning about Time make any sense? Do different libraries treat Time in different ways, such that some are suitable for simulations, while others are not?
Martin
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

I stumbled across avika but haven't looked at it. One of my problems is to decide where to dive in. Should I look at yampa, sodium or avika when I want to do simulations? Am 03/17/2014 07:01 AM, schrieb David Sorokin:
Martin,
It depends on that how FRP is defined.
So, in F# it is usually associated with the Async monad and IObservable interface.
If we will follow in the same direction then the short answer is definitely yes. An example is my simulation library Aivika [1].
My Process monad allows describing the discontinuous processes (inspired by the Async monad from F#). There is also the Signal type (inspired by the .NET IObservable interface) that allows notifying about some (.NET-like) events such as an update of the variable.
Then the characteristic function in a context of FRP would be the next one:
processAwait :: Signal a -> Process a
There is an opposite direction from the Process computation to signals through the Task type but it is a little bit complicated as the discontinuous process can be canceled, or an IO exception may arise within the computation.
But the simulation field is too big and diverse to assert something general.
Thanks, David

depends on the type of simulation!
indeed, is your modelling needs "casual" or "acausall"? The latter would be
say "i'm describing a circuit board" the former would be "given this change
in inputs, respond like so". Not every simulation needs to be of the former
sort!
On Mon, Mar 17, 2014 at 2:07 PM, martin
I stumbled across avika but haven't looked at it. One of my problems is to decide where to dive in. Should I look at yampa, sodium or avika when I want to do simulations?
Martin,
It depends on that how FRP is defined.
So, in F# it is usually associated with the Async monad and IObservable interface.
If we will follow in the same direction then the short answer is definitely yes. An example is my simulation library Aivika [1].
My Process monad allows describing the discontinuous processes (inspired by the Async monad from F#). There is also the Signal type (inspired by the .NET IObservable interface) that allows notifying about some (.NET-like) events such as an update of the variable.
Then the characteristic function in a context of FRP would be the next one:
processAwait :: Signal a -> Process a
There is an opposite direction from the Process computation to signals
Am 03/17/2014 07:01 AM, schrieb David Sorokin: through the Task type but it is a little bit
complicated as the discontinuous process can be canceled, or an IO exception may arise within the computation.
But the simulation field is too big and diverse to assert something general.
Thanks, David
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

I agree that it depends on the type of simulation. As usual in the life, there is no universal method. 17.03.2014 23:07, Carter Schonwald ?????:
depends on the type of simulation!
indeed, is your modelling needs "casual" or "acausall"? The latter would be say "i'm describing a circuit board" the former would be "given this change in inputs, respond like so". Not every simulation needs to be of the former sort!
On Mon, Mar 17, 2014 at 2:07 PM, martin
mailto:martin.drautzburg@web.de> wrote: I stumbled across avika but haven't looked at it. One of my problems is to decide where to dive in. Should I look at yampa, sodium or avika when I want to do simulations?
Am 03/17/2014 07:01 AM, schrieb David Sorokin: > Martin, > > It depends on that how FRP is defined. > > So, in F# it is usually associated with the Async monad and IObservable interface. > > If we will follow in the same direction then the short answer is definitely yes. An example is my simulation library > Aivika [1]. > > My Process monad allows describing the discontinuous processes (inspired by the Async monad from F#). There is also the > Signal type (inspired by the .NET IObservable interface) that allows notifying about some (.NET-like) events such as an > update of the variable. > > Then the characteristic function in a context of FRP would be the next one: > > processAwait :: Signal a -> Process a > > There is an opposite direction from the Process computation to signals through the Task type but it is a little bit > complicated as the discontinuous process can be canceled, or an IO exception may arise within the computation. > > But the simulation field is too big and diverse to assert something general. > > Thanks, > David > > [1] http://hackage.haskell.org/package/aivika
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org mailto:Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
participants (3)
-
Carter Schonwald
-
David Sorokin
-
martin