On 27 Sep 2013 at 0:27, Klaim - Joël Lamotte wrote:
Can you tell us more about what you mean by Simulation library ? It's a broad concept.
My expectation is that: 1. you have some data representing the state of the simulation; 2. you have a set of rules that have to be applied on each cycle of the simulation; (each cycle might correspond to a time frame but it's important that it's "fixed"); 3. you have some set of events that needs to be triggered (maybe by the rules?); 4. the library take all that in, then provide a function to iterate to the next cycle; 5. each cycle is double buffered (or something similar) that is: a. the library first keep a read-only copy of the state of the last cycle and the state of the next cycle; b. the rules are applied using the read-only last cycle state to modify the state of the next cycle; c. meanwhile, events are collected; d. once the cycle is complete, the events are dispatched or provided as a set to the user code; e. the events will also be used by the rules on the next cycle, which makes it a simulation;
If it's not what the library is about, then I'll need some clarifications. :)
If it is this, then this is a very common design pattern in my testing code. I would have a suspicion that such a library wouldn't offer enough advantages that would cause me to replace my bespoke testing code with it, but if it is (a) highly multithreadable (b) highly scalable (iii) highly configurable, I might just be persuaded. I'd certainly like to learn more. Niall -- Currently unemployed and looking for work. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/