On Tuesday 18 August 2009, Maurí­cio CA wrote:

...

...) But for simulation kind-of problems, in which I think OO really fits the best, what's the haskell way to structure such problems? I once thought maybe I can use the State monad to simulate objects. But it's really hard for me to implement, because I think State monad is used to simulate a global shared state, is it right?

Then what's the best way to simulate private states or just instead how to solve simulation problems such as a physical engine using the haskell way?

A physical engine can be simulated using pure code, with a function from timestep to state. (Of course, that doesn't hold when you want to deal with user interaction.) I think there is no general answer to your question. My sugestion is to describe an example you would like to work with.

Hi, I did a medium sized mobility models simulator this way. The simulation is represented as an infinite list of states, where the next state is created by applying a state transformation ("next") function to the previous state. This has the advantage that you can calculate values based on more than one state. The downside is that if you need to look back 100 stesp, you need to remember 100 states (though if enough of it is unchanged and shared then it's not really that much of a problem). As far as the details go -- different parts of the simulator are executed in different monads. "god-mode" code, like the "next" function has the type nextStep :: World -> World but the mobility model implementation (which tells a node how to move) is a stateful computation run by nextStep: mobilityModel :: StateT NodeState (Reader World) () But as Maurí­cio said -- please describe what you want to achieve. At least what kind of simulation you'd like to write. -- Thanks! Marcin Kosiba

You could read: http://www.cs.nott.ac.uk/~nhn/FoPAD2007/Talks/nhn-FoPAD2007.pdf http://haskell.cs.yale.edu/yale/papers/haskell-workshop03/yampa-arcade.pdf http://www.cs.nott.ac.uk/~nhn/Talks/HW2002-FRPContinued.pdf http://www.haskell.org/yale/papers/haskellworkshop02/index.html http://www.haskell.org/haskellwiki/Frag Basically, even in an imperative solution, if you have complex dependencies between objects at the same time T, then my experience tells me your into trouble, it's better to make all objects at time T depend on the state of other objects at time T-dT. If you absolutely need to know at time T what the state of another object is at time T, the network of dependencies needs to be rearranged dynamically, and you might get different results (or endless loops if you do it badly) in the case of mutual dependencies. This is what Elerea does. On Wed, Aug 19, 2009 at 12:40 AM, Eric Wong wrote:

I used to think about a physical engine in a similar way, and I think it can work. But in some simulations that objects have lots of dependencies on others can be tricky. For instance, object o1 depends on o2, if we represent them in pure values, when we update o2, then o1 must be updated with a new o2 value, isn't it?

Recently I want to implement the digital circuit simulation in SICP using Haskell as an exercise. In the Scheme version, each Wire is represented as a function with local states. It records the signal on the wire and actions it will take when the signal changes to activate other wires. How to represent the Wire in haskell purely?

If I use State Monad (yes, it's pure :) to repsent a wire with local state, the interaction between connected wires is really tricky to implement. any ideas?

thanks. Eric _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

It is interesting to note that recent work on AFRP (arrow-based FRP) - namely "Causal Commutative Arrows" - optimizes a complete circuit of arrows ("interconnected objects" if you prefer to think that way) that all have local state and local feedback loops into one large state and feedback loop, essentially what optimized imperative simulations also do (e.g. thousands of moving particles that are treated as a single state block of position/velocity pairs). Together with stream fusion the researchers working on this were able to generate optimized code that runs hundreds (!!!) times faster than the best GHC could do. Impressive isn't it. Unfortunately it will only work on static networks, not those with dynamic switches in it, but I'm pretty sure that within say 5 years, this will all be settled and it will become exiting times for simulation developers, we will finally be pure, lazy *and* fast; it just needs a little push (since it's now mostly pulling, okay I'll stop the nonsense, couldn't resist the nerd talk ;-) On Wed, Aug 19, 2009 at 1:29 AM, Ertugrul Soeylemez wrote:

Eric Wong wrote:

...

I used to think about a physical engine in a similar way, and I think it can work. But in some simulations that objects have lots of dependencies on others can be tricky. For instance, object o1 depends on o2, if we represent them in pure values, when we update o2, then o1 must be updated with a new o2 value, isn't it?

This is something handled best by functional reactive programming. See Peter Verswyvelen's post. It allows you to encode this purely in an excitingly elegant way.

...

Recently I want to implement the digital circuit simulation in SICP using Haskell as an exercise. In the Scheme version, each Wire is represented as a function with local states. It records the signal on the wire and actions it will take when the signal changes to activate other wires. How to represent the Wire in haskell purely?

If I use State Monad (yes, it's pure :) to repsent a wire with local state, the interaction between connected wires is really tricky to implement. any ideas?

You don't. Either you use a state monad to hold _all_ wires (objects) in, say, a Map, a Set or an Array, or you use a completely different approach (like FRP). In other words, your state monad should represent all wires, not just one, because all wires together make up the state you want to work with.

Greets, Ertugrul.

-- nightmare = unsafePerformIO (getWrongWife >>= sex) http://blog.ertes.de/

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

2009/08/18 Eric Wong :

When I was using C and Python, I used to think of most applications in an simulation way.

By "simulation way", do you mean "object-oriented way"? -- Jason Dusek

Sorry for a mistake. "Shiyou Wang" is my identity in a private chinese group. Sorry for the confusing. :-( Eric

When I was using C and Python, I used to think of most applications in an simulation way. I think it's right to say that programs are simulations. But now I have to change my mind in Haskell, I have to think in a data-flow way, that is: data in, processing using function composition, data out.

You have to think there's no in and out, since there's no state and so no before and after. And no flow, since time is just an ilusion of users. In Haskell, a program just "is". Sorry, could not resist the Jedi talk... Hope you like the language. Best, Maurício