[reactive] FRP + physics / status of hpysics

[Daniel Bünzli]

Le 6 mars 09 à 11:17, Peter Verswyvelen a écrit :

[...]

> without using recursive signal functions,

If this is because there's this limitation in the frp system you use  
then better fix the system. Soon or later it you'll want it elsewhere.  
A recursive reactive signal just means that some of what your reactive  
program computed will be usefull/necessary for the next step. You'll  
see that happen very quickly (e.g. any simple reactive state machine).

> It feels as if none of the current FRP engines can handle physics  
> correctly, since a typical physics implementations requires "time  
> backtracking", in the sense that when you want to advance the  
> current simulation time by a timestep, collision events can happen  
> during that time interval, and hence the FRP engine can only advance  
> time until the earliest collision event. So to do physics *with* an  
> FRP engine, the implementation and maybe even semantics of the FRP  
> system might need to be changed.

I stumbled on the same problems. I don't think that's a question of  
frp semantics. I also don't think that these are unsurmountable,  
however in the end it turns into the question whether you do really  
gain something in implementing that with frp (vs. having an frp  
interface to the system; a clear benefit to me).

The problem is that when you are doing a timestep with the physics  
engine there are a lot of "things" that happen internally that you  
don't want the outside world (which implements the concrete simulation  
logic) to see. Moreover these "things" are very much control flow  
oriented. This means that you have to introduce intermediary clean  
signals that are the result of sampling the dirty (internal) signals  
when the timestep has eventually finished and a lot of control signals/ 
events system to handle the control flow.

What we need to remember is that frp is a form of dataflow  
programming. Now what I suspect is that the way physics engines are  
currently programmed are very much control flow oriented, notably  
because you need to be efficient and also because the discrepancy  
between ideal real numbers/continuous time and our floating point  
numbers/discrete time steps shows up very quickly and you have to  
resort to ad-hoc and dirty strategies to handle it.

So my guess at that point is that either you can can find a dataflow  
oriented implementation of physics engines and then using frp makes  
sense to implement it. Either as you suggest :

> *Using* a physics engine as a blackbox inside an FRP system might  
> make more sense.

Best,

Daniel

P.S. I'm only on the reactive list keep me on the cc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/reactive/attachments/20090306/f12e9bbb/attachment.htm