You can subscribe to this list here.
2004 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}
(1) 
_{Sep}

_{Oct}

_{Nov}

_{Dec}


2005 
_{Jan}
(1) 
_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

2009 
_{Jan}

_{Feb}

_{Mar}
(1) 
_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}
(17) 
_{Sep}
(34) 
_{Oct}

_{Nov}

_{Dec}

2010 
_{Jan}

_{Feb}
(100) 
_{Mar}
(122) 
_{Apr}
(5) 
_{May}

_{Jun}
(17) 
_{Jul}
(36) 
_{Aug}
(9) 
_{Sep}
(111) 
_{Oct}
(92) 
_{Nov}
(76) 
_{Dec}
(26) 
2011 
_{Jan}
(3) 
_{Feb}
(35) 
_{Mar}
(36) 
_{Apr}
(10) 
_{May}
(9) 
_{Jun}
(2) 
_{Jul}
(3) 
_{Aug}
(2) 
_{Sep}

_{Oct}
(7) 
_{Nov}
(12) 
_{Dec}

2012 
_{Jan}
(19) 
_{Feb}
(1) 
_{Mar}
(4) 
_{Apr}
(1) 
_{May}
(6) 
_{Jun}
(69) 
_{Jul}
(21) 
_{Aug}
(12) 
_{Sep}
(14) 
_{Oct}
(1) 
_{Nov}
(3) 
_{Dec}

2013 
_{Jan}
(6) 
_{Feb}
(1) 
_{Mar}
(6) 
_{Apr}
(3) 
_{May}
(6) 
_{Jun}
(1) 
_{Jul}

_{Aug}

_{Sep}

_{Oct}
(2) 
_{Nov}
(3) 
_{Dec}

2014 
_{Jan}

_{Feb}

_{Mar}
(6) 
_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

2015 
_{Jan}
(4) 
_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}
(1) 
_{Dec}
(3) 
2016 
_{Jan}
(6) 
_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 



1

2

3

4

5

6

7

8

9

10

11

12
(3) 
13

14

15

16

17

18

19

20

21

22

23
(1) 
24
(1) 
25

26
(1) 
27

28

29

30

31



From: Lukasz Stafiniak <lukstafi@gm...>  20120526 13:17:45

On Thu, May 24, 2012 at 12:38 PM, Lukasz Kaiser <lukaszkaiser@...> wrote: > >> I've mentioned that Toss "is undecided" whether to be a system >> modeling tool or a cognitive system. [...] > > it is crucial to model many agents, and not only their possible actions, > but foremost their goals and preferences. Then, to run the system, you need to > perform game simulations, not only solve equations  and in this way modeling > gets this cognitive system flavour  because you need to play the game. Maybe > in some time we will actually see, that there isn't really a big difference ;). What I think distinguishes a cognitive system from a modeler tool is: (1) learning, (2) integration, (3) continuous operation (could be called autonomous or online operation or continuous initiative, i.e. not just a commandresponse model; continuous operation "per force" guarantees transfer learning). 
From: Lukasz Kaiser <lukaszkaiser@gm...>  20120524 10:39:43

Hi, > I've mentioned that Toss "is undecided" whether to be a system > modeling tool or a cognitive system. [...] > Well, that was just a disclaimer to posting a recent development in > the system modeler world. > http://blog.wolfram.com/2012/05/23/announcingwolframsystemmodeler/ I like the system modeler a lot  at least from what I see on their website :). But it still lacks this one thing that is essential in Toss  modeling players! In fact it  and all competitors they mention  should be called a deterministic system modeler. And I am convinced, as always, that this is not enough and that it is crucial to model many agents, and not only their possible actions, but foremost their goals and preferences. Then, to run the system, you need to perform game simulations, not only solve equations  and in this way modeling gets this cognitive system flavour  because you need to play the game. Maybe in some time we will actually see, that there isn't really a big difference ;). Best! Lukasz 
From: Lukasz Stafiniak <lukstafi@gm...>  20120523 19:27:26

I've mentioned that Toss "is undecided" whether to be a system modeling tool or a cognitive system. It was initially designed as the first, but has recently drifted a bit towards the other, and I like it, cognition is very exciting ("the ultimate thing" in some sense). But it does not have a cognitive architecture integrating the different modules. Well, that was just a disclaimer to posting a recent development in the system modeler world. http://blog.wolfram.com/2012/05/23/announcingwolframsystemmodeler/ 
From: Lukasz Kaiser <lukaszkaiser@gm...>  20120512 18:54:26

> Great news! What about waiting with 0.8 release till next weekend? > I'll finally start taking a look at recent commits next week. I can wait, but one reason I wanted to do it is that I want to remove Term ml and some of the symbolic stuff just after that  but I prefer to have a release to go back to in case we need it back one day. So maybe I should just do it, and your testing and help will be needed anyway, especially when I get to rewriting diff solver for speed, as you have much better feeling for where we are slow! So, what do you think, should I wait or go? Lukasz 
From: Lukasz Stafiniak <lukstafi@gm...>  20120512 16:36:07

On Sat, May 12, 2012 at 5:32 PM, Lukasz Kaiser <lukaszkaiser@...> wrote: > Hi. > > I was recently interested in some bioinformatic problems > and of course I started modelling them in Toss. This is why > we now have a cell cycle example, a simple model from Tyson > from 1991. On the way, I corrected a few bugs we had with > continuous dynamics and added animations to the JS interface. > > One interesting thing about the implementation of ODEs in Toss > is that it works symbolically: you can leave free parameters, but > it is slower due to that of course. I never knew whether that was > a good decision, but now I could finally test it a bit. [...] > numerical part faster in Toss. At least I think I will focus more on > that in the next release. But first: 0.8  I hope to make it soon :). Great news! What about waiting with 0.8 release till next weekend? I'll finally start taking a look at recent commits next week. Cheers. 
From: Lukasz Kaiser <lukaszkaiser@gm...>  20120512 15:33:47

Hi. I was recently interested in some bioinformatic problems and of course I started modelling them in Toss. This is why we now have a cell cycle example, a simple model from Tyson from 1991. On the way, I corrected a few bugs we had with continuous dynamics and added animations to the JS interface. One interesting thing about the implementation of ODEs in Toss is that it works symbolically: you can leave free parameters, but it is slower due to that of course. I never knew whether that was a good decision, but now I could finally test it a bit. The example (in examples/CellCycleTyson1991) results in the following system of ODEs (using v0 ... v5 for variable names here), assuming we leave the two significant parameters, k4 and k6, symbolic. v0' = 0.015 + 200. * v0 * v3 v1' = 0.6 * v2 + k6 * v4 v2' = 100. * v2 + k6 * v4 + 100. * v3 v3' = 100. * v3 + 100. * v2 + 200. * v0 * v3 v4' = k6 * v4 + 0.018 * v5 + k4 * v5 * v4 * v4 v5' = 0.018 * v5 + 200. * v0 * v3 + k4 * v5 * v4 * v4 These two parameters, k4 and k6, range, say, from 10 to 1000 (k4) and from 0 to 10 (k6), and normally, e.g. with k4=180, k6=1, the system oscilates with a peak of v5 after time t=30, more or less. One interesting question, which Francois Fages and others solve with BIOCHAM in contraintes.inria.fr/~fages/Papers/RBFS09tcs.pdf is whether one can find k4 and k6 such that v5 at, say, t=30, is > 0.3. The idea of doing it symbolically is that, instead of searching through the parameter space, one computes a conjunction of assertions over the firstorder theory of the real field and uses a solver for that. Since RungeKutta equations, and we use the standard RK4 as described on http://en.wikipedia.org/wiki/Runge%E2%80%93Kutta_methods with a constant time interval (we use h=0.005 in each step) operates on polynomials, it is easy to generate the system of polynomial equations for a simulation of N steps. It is even linear in N and uses (N+1)*6+2 free variables: v0atK, v1atK, ..., v5atK for k=0,...,N to represent the values of each variable vi at time step K, and the two parameters k4, k6. I made a basic interface in TermTest to generate these constraints in the smt2 format (used in SMT competitions), so if you first do in Toss "make Arena/TermTest.native" and then run "./TermTest.native steps 10" you will get the formula for 10 steps. You can then add assertions about k4, k6, or the final values as you wish and feed it to any QF_NRA solver. I generated the formula for 100 steps of the above Tyson model and added the intervals for k4, k6, and initial values (0,0,1,0,0,0). The file in smt2 format is attached. Then I ran the best solver I know on it, and after 15 minutes it still did nothing. This does not look promising, because the system with only these constraints should be trivially satisfiable. But it also shows that this kind of formulas are probably very hard for symbolic solvers. Moreover, numercal methods and especially evolutionary optimization techniques such as CMAES http://en.wikipedia.org/wiki/CMAES http://hal.inria.fr/docs/00/58/36/69/PDF/hansen2011impacts.pdf give much better results here much faster. So maybe it is time to remove some of the symbolic stuff and work more on making the numerical part faster in Toss. At least I think I will focus more on that in the next release. But first: 0.8  I hope to make it soon :). Best! Lukasz 