#### Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Options

# Discrete simulation code tutorial

There's a very preliminary tutorial to the C++ code library (uploaded to the Azimuth Code Project) at Discrete simulation code tutorial. It's not hugely comprehensible yet, but I'll probably slowly refine it over time.

• Options
1.

Comment Source:If you like to, you could also add a link to this page on the home page of the Azimuth code project.
• Options
2.

Hi David,

I couldn't build your C++ DSE code on archlinux with the existing makefile so a couple of friends and I made some mods to the source and added a cmake makefile and a readme.

I emailed a zip to the email address listed for you on the google repo 2 or 3 weeks ago. Did you receive it?

Comment Source:Hi David, I couldn't build your C++ DSE code on archlinux with the existing makefile so a couple of friends and I made some mods to the source and added a cmake makefile and a readme. I emailed a zip to the email address listed for you on the google repo 2 or 3 weeks ago. Did you receive it?
• Options
3.
edited February 2012

Hi Jim,

I received your email, and had been thinking about the issues you raised. Unfortunately pretty much every aspect of my life has gone wrong recently so I just haven't had time to actually respond. (This isn't to elicit sympathy, just to say that for the forseeable future I'm unlikely to have the time or resources to even read Azimuth regularly, let alone actually do anything. So regard me as a priori incredibly flaky and unreliable about doing anything or even responding to email.)

I think a cmake file would be very useful addition (I just never got around to learning cmake myself). Regarding the order of standard header includes, they were the ones that worked on ubuntu at the time I wrote it, but C++ headers are notorious for being changed and causing problems like this, so I can imagine that the modifications are required. Feel free to commit either of those changes: the code is completely open source.

You also asked about making this available via a "server in the cloud". I don't have any good ideas about that: part of the design was to embed the modeling within any C++ program rather than writing a more complete "simulation environment", which

• on the one hand makes it easier to use a standard programming language for writing/reusing other parts of the simulation investigation system (eg, how you want to log the data, visualise it, etc, which may be constrained by legacy code you've already written/other things you want to interface with/etc)

• but the lack of "standard" facilities makes it difficult to provide as a "drop your model code in" cloud service.

I'm not sure what would be the best -- in the sense of acheiving the most useful result given limited volunteer developer time -- way of making the code easily usable in a cloud server sense. Again, if you've got any idea feel free to both run with it and ask me anything related to it.

Comment Source:Hi Jim, I received your email, and had been thinking about the issues you raised. Unfortunately pretty much every aspect of my life has gone wrong recently so I just haven't had time to actually respond. (This isn't to elicit sympathy, just to say that for the forseeable future I'm unlikely to have the time or resources to even read Azimuth regularly, let alone actually do anything. So regard me as _a priori_ incredibly flaky and unreliable about doing anything or even responding to email.) I think a cmake file would be very useful addition (I just never got around to learning cmake myself). Regarding the order of standard header includes, they were the ones that worked on ubuntu at the time I wrote it, but C++ headers are notorious for being changed and causing problems like this, so I can imagine that the modifications are required. Feel free to commit either of those changes: the code is completely open source. You also asked about making this available via a "server in the cloud". I don't have any good ideas about that: part of the design was to embed the modeling within any C++ program rather than writing a more complete "simulation environment", which * on the one hand makes it easier to use a standard programming language for writing/reusing other parts of the simulation investigation system (eg, how you want to log the data, visualise it, etc, which may be constrained by legacy code you've already written/other things you want to interface with/etc) * but the lack of "standard" facilities makes it difficult to provide as a "drop your model code in" cloud service. I'm not sure what would be the best -- in the sense of acheiving the most useful result given limited volunteer developer time -- way of making the code easily usable in a cloud server sense. Again, if you've got any idea feel free to both run with it and ask me anything related to it.
• Options
4.

FWIW, I had been thinking a lot about simulation recently and, in the case of the kind of ecological/human systems -- as opposed systems which naturally do "move to" equilibrium behaviour -- I was thinking about with that simulation code, I'm not sure that that approach is the best way of doing things. This brief note describes what I was thinking about in case it's of any use to anyone else on Azimuth thinking about this stuff.

The reason I think the high-level design is acutally not the best fit is that the simple models you want to look at a tend to be simple low-order Markov or, in more simple terms, have very limited "memory" that will affect the future evolution. This is particularly so if you've got a lot of "operators that map large amounts of the state space to the same state" in the model, such as

1. suppose you've got a minimal breeding population below which the model says a species goes extinct: then regardless of how you get there, the behaviour (at least for that species) remains the same;

2. suppose foxes naturally eat some stochastic number of rabbits in a given range of rabbits, then once the number of foxes is above a given level they'll eat all the rabbits regardless of the precise number of foxes;

and similar situations. Since the published code follows a single simulation path, it can't take advantage of the fact that different initial paths will have the same (stochatically defined, of course) behaviour once they "pass through the same state" (I believe the nice term "coalesce" is already defined for a more precise notion, so stick with the long form...), and I can't think of a reasonably efficient way to modify the code to acheive it.

So I was thinking about how one could

1. build a representation of the "Markov transition matrix" and then

2. use the single-step representation to draw conclusions about longer term behaviour.

In terms of long term behaviour I'm not thinking about strict equilibrium state behaviour, because I think that this is less likely to be an occurrence in practical ecological modeling: apart from anything else if a model does tend to an equilibirum state it's probably not in need of human "assistance". But one could certainly envisage that the complete transition matrix wouldn't need to be computed (which would be computationally completely prohibitive for any interesting sized model) in order to draw useful conclusions in step 2.

One thing that I was thinking about was something that would, in reliable practice, be unacheivable using just standard C++ was taking the literal model code and doing things like automatic differentiation on it, then fixing some of the parameters -- particularly given knowledge of operators like $max$ occuring in the models -- and specialising the resulting code to produce a simpler -- and hence faster -- piece of code for estimating numerical values for part of the transition matrix. (Actually, there's more details, but they're not completely coherent in my mind yet, so I won't write them unless anyone really wants to know.) This kind of thing is the things that the popular LLVM codebase would provide most of the heavy lifting for this JIT optimisation and compilation, with the "simulation framework" providing some high-level priming of certain facts about the program obtained from the model that would be very difficult for the general purpose LLVM routines to "infer".

It's unlikely I'm going to be actually implementing any of these ideas in the near future, so if anyone wants to try any of these things feel free.

Comment Source:FWIW, I had been thinking a lot about simulation recently and, in the case of the kind of ecological/human systems -- as opposed systems which naturally do "move to" equilibrium behaviour -- I was thinking about with that simulation code, I'm not sure that that approach is the best way of doing things. This brief note describes what I was thinking about in case it's of any use to anyone else on Azimuth thinking about this stuff. The reason I think the high-level design is acutally not the best fit is that the simple models you want to look at a tend to be simple low-order Markov or, in more simple terms, have very limited "memory" that will affect the future evolution. This is particularly so if you've got a lot of "operators that map large amounts of the state space to the same state" in the model, such as 1. suppose you've got a minimal breeding population below which the model says a species goes extinct: then regardless of how you get there, the behaviour (at least for that species) remains the same; 2. suppose foxes naturally eat some stochastic number of rabbits in a given range of rabbits, then once the number of foxes is above a given level they'll eat all the rabbits regardless of the precise number of foxes; and similar situations. Since the published code follows a single simulation path, it can't take advantage of the fact that different initial paths will have the same (stochatically defined, of course) behaviour once they "pass through the same state" (I believe the nice term "coalesce" is already defined for a more precise notion, so stick with the long form...), and I can't think of a reasonably efficient way to modify the code to acheive it. So I was thinking about how one could 1. build a representation of the "Markov transition matrix" and then 2. use the single-step representation to draw conclusions about longer term behaviour. In terms of long term behaviour I'm not thinking about strict equilibrium state behaviour, because I think that this is less likely to be an occurrence in practical ecological modeling: apart from anything else if a model does tend to an equilibirum state it's probably not in need of human "assistance". But one could certainly envisage that the complete transition matrix wouldn't need to be computed (which would be computationally completely prohibitive for any interesting sized model) in order to draw useful conclusions in step 2. One thing that I was thinking about was something that would, in reliable practice, be unacheivable using just standard C++ was taking the literal model code and doing things like [[automatic differentiation]] on it, then fixing some of the parameters -- particularly given knowledge of operators like $max$ occuring in the models -- and specialising the resulting code to produce a simpler -- and hence faster -- piece of code for estimating numerical values for part of the transition matrix. (Actually, there's more details, but they're not completely coherent in my mind yet, so I won't write them unless anyone really wants to know.) This kind of thing is the things that the popular [LLVM](www.llvm.org) codebase would provide most of the heavy lifting for this JIT optimisation and compilation, with the "simulation framework" providing some high-level priming of certain facts about the program obtained from the model that would be very difficult for the general purpose LLVM routines to "infer". It's unlikely I'm going to be actually implementing any of these ideas in the near future, so if anyone wants to try any of these things feel free.
• Options
5.

Hi David,

Thanks for your very helpful response. It's stimulated me to want to write some climate code and John has already proposed an energy balance spec (which just got a lot more complex after one comment :)). So now I have a lot more reading to do!

I've been playing a bit with automatic differentiation code in haskell written by Dan Piponi and the library written by Lennart Augusstson and based on papers by Jerzy Karczmarczuk. Fascinating stuff which immediately got me, even if I've not got it yet.

The llvm backend to haskell seemed to work well on my previous compiler version and benchmarks appear to be improving all the time. I understand that changes have been requested from the llvm folks to match impedances with ghc's IR.

I'd be happy to try out the fad library given some specification. There may be some delay because, as usual, I've upgraded my ghc to 7.4.1 so breaking a majority of libraries, including fad. This will be corrected.

John Baez has said he could enquire about setting up a web service account to run interactive software. From my POV javascript seems an obvious possible choice ("assemby language of the web") for the front-end. Whether there would be a possibility of running compilers for other languages I don't yet know.

I'd have to learn a lot more before I could comment on you markov model ideas.

I hope you'll be able to boost your mileage soon if that's not an inappropriate metaphor for an environmental blog .

Cheers

Comment Source:Hi David, Thanks for your very helpful response. It's stimulated me to want to write some climate code and John has already proposed an energy balance spec (which just got a lot more complex after one comment :)). So now I have a lot more reading to do! I've been playing a bit with automatic differentiation code in haskell written by Dan Piponi and the library written by Lennart Augusstson and based on papers by Jerzy Karczmarczuk. Fascinating stuff which immediately got me, even if I've not got it yet. The llvm backend to haskell seemed to work well on my previous compiler version and benchmarks appear to be improving all the time. I understand that changes have been requested from the llvm folks to match impedances with ghc's IR. I'd be happy to try out the fad library given some specification. There may be some delay because, as usual, I've upgraded my ghc to 7.4.1 so breaking a majority of libraries, including fad. This will be corrected. John Baez has said he could enquire about setting up a web service account to run interactive software. From my POV javascript seems an obvious possible choice ("assemby language of the web") for the front-end. Whether there would be a possibility of running compilers for other languages I don't yet know. I'd have to learn a lot more before I could comment on you markov model ideas. I hope you'll be able to boost your mileage soon if that's not an inappropriate metaphor for an environmental blog . Cheers
• Options
6.

David,

In a recent comment, I mentioned the idea of estimating linear Markov models of the climate. This has some precedent in the literature under the name "linear inverse models". They look like this:

$$d\mathbf{x}/dt = \mathbf{Lx} + \mathbf{F} + \mathbf{\xi}$$ Here $\mathbf{x}$ is a vector of climate variables, $\mathbf{L}$ is a dynamical transition matrix (not a matrix of Markov transition probabilities, but can be used to derive one), $\mathbf{F}$ is some exogenous time-dependent forcing, and $\mathbf{\xi}$ is a noise process.

(By the way, in the above expression, why is the first "d" italicized but the second isn't? It seems to have to do with the boldface font.)

Usually the system is first dimensionally reduced using principal component analysis before estimating the transition matrix (so the climate vector is just the projection onto leading components).

One question is how well these models, estimated from relatively short time steps (months), can predict climate out to decadal or longer time scales. Climatologists have actually used them to try to predict climate modes of variability, like ENSO or the AMO.

Comment Source:David, In [a recent comment](http://www.math.ntnu.no/~stacey/Mathforge/Azimuth/comments.php?DiscussionID=938&Focus=6274#Comment_6274), I mentioned the idea of estimating linear Markov models of the climate. This has some precedent in the literature under the name "linear inverse models". They look like this: $$d\mathbf{x}/dt = \mathbf{Lx} + \mathbf{F} + \mathbf{\xi}$$ Here $\mathbf{x}$ is a vector of climate variables, $\mathbf{L}$ is a dynamical transition matrix (not a matrix of Markov transition probabilities, but can be used to derive one), $\mathbf{F}$ is some exogenous time-dependent forcing, and $\mathbf{\xi}$ is a noise process. (By the way, in the above expression, why is the first "d" italicized but the second isn't? It seems to have to do with the boldface font.) Usually the system is first dimensionally reduced using principal component analysis before estimating the transition matrix (so the climate vector is just the projection onto leading components). One question is how well these models, estimated from relatively short time steps (months), can predict climate out to decadal or longer time scales. Climatologists have actually used them to try to predict climate modes of variability, like ENSO or the AMO.
• Options
7.

By the way, in the above expression, why is the first "d" italicized but the second isn't? It seems to have to do with the boldface font.

if you write two letters without separation, like $CO_2$ or $dt$ it will come out straight in iTex.

Comment Source:> By the way, in the above expression, why is the first "d" italicized but the second isn't? It seems to have to do with the boldface font. if you write two letters without separation, like $CO_2$ or $dt$ it will come out straight in iTex.
• Options
8.

if you write two letters without separation, like $CO_2$ or $dt$ it will come out straight in iTex.

Right, it has nothing to do with the boldface font. Andrew Stacey and other iTeX fans claim this is a 'feature', and you just have to learn to leave spaces between letters if you want them to come out italic instead of roman. I consider it more of a nuisance.

Comment Source:> if you write two letters without separation, like $CO_2$ or $dt$ it will come out straight in iTex. Right, it has nothing to do with the boldface font. Andrew Stacey and other iTeX fans claim this is a 'feature', and you just have to learn to leave spaces between letters if you want them to come out italic instead of roman. I consider it more of a nuisance.
• Options
9.
edited March 2012

Hi Jim et al,

One thing I didn't mention explicitly was one of the things I was thinking about using automatic differentiation for.

Suppose we're considering a system with a transition $\vec{y}=\vec{f}(\vec{x})$. Then for a point $\vec{x}_0$ that maps to a point $\vec{y}_0$, it is well known in the simple case that there's only one point mapping to $\vec{y}_0$ then the pdf $p_x$ of $\vec{x}$ is related to the pdf $p_y$ of $\vec{y}$ by:

$$p_y(\vec{y}0) d \vec{y} \propto (abs(det (\partial \vec{y}/\partial \vec{x}|{x_0})))^{-1} p_x(\vec{x}_0) d \vec{x}$$ where $\partial \vec{y}/\partial \vec{x}$ is the Jacobian matrix of the transformation $\vec{f}$. (This is just stating the change of variables rule for an integral in the particular case of a pdf.) In the general case there's a sum over all the points $\vec{x}$ that map to $\vec{y}_0$, but that complicates the notation without affecting the particular issues here.

It doesn't seem unreasonable to try and track how the pdf evolves by looking at samples and doing some form of "extrapolation" (eg, using splines, or quadrature, or something else). So this all looks ok, but what happens for something like $y=min(x,T)$ where $T$ is a fixed constant. Remember, we just want to know what to do to find the value at a particular point, not necessarily any closed form.

Well, in this 1-D case if $x_0 \le T$ then $\partial y/\partial x|_{x_0}=1$. If $x_0 \gt T$, then $\partial y/\partial x|_{x_0}=0$ but we also know from probability theory "the result" should be a Dirac delta function (since we've got a finite amount of probability mass at the exact mathematical point $T$), which if you squint you can imagine might come from $1/0$. But what happens in multiple dimensions? For example, for input variables $x$ and $y$ and output variables $u$ and $v$, what is the relationship between the input and output pdfs in the various cases for the two cases $b \le T$ and $b \gt T$ for the following simple (not meant to actually model anything) example that still shows some of the issues?

a := 2 * x
b := a + y
c := min(b,T)
d := c / b
u := a * d
f := y * d
v := 2 * f



I was working towards an idea, hope to get back to it at some point...

Comment Source:Hi Jim et al, One thing I didn't mention explicitly was one of the things I was thinking about using automatic differentiation for. Suppose we're considering a system with a transition $\vec{y}=\vec{f}(\vec{x})$. Then for a point $\vec{x}_0$ that maps to a point $\vec{y}_0$, it is well known _in the simple case that there's only one point mapping to_ $\vec{y}_0$ then the pdf $p_x$ of $\vec{x}$ is related to the pdf $p_y$ of $\vec{y}$ by: $$p_y(\vec{y}_0) d \vec{y} \propto (abs(det (\partial \vec{y}/\partial \vec{x}|_{x_0})))^{-1} p_x(\vec{x}_0) d \vec{x}$$ where $\partial \vec{y}/\partial \vec{x}$ is the Jacobian matrix of the transformation $\vec{f}$. (This is just stating the change of variables rule for an integral in the particular case of a pdf.) In the general case there's a sum over all the points $\vec{x}$ that map to $\vec{y}_0$, but that complicates the notation without affecting the particular issues here. It doesn't seem unreasonable to try and track how the pdf evolves by looking at samples and doing some form of "extrapolation" (eg, using splines, or quadrature, or something else). So this all looks ok, but what happens for something like $y=min(x,T)$ where $T$ is a fixed constant. Remember, we just want to know what to do to find the _value_ at a particular point, not necessarily any closed form. Well, in this 1-D case if $x_0 \le T$ then $\partial y/\partial x|_{x_0}=1$. If $x_0 \gt T$, then $\partial y/\partial x|_{x_0}=0$ but we also know from probability theory "the result" should be a Dirac delta function (since we've got a finite amount of probability mass at the exact mathematical point $T$), which if you squint you can imagine might come from $1/0$. But what happens in multiple dimensions? For example, for input variables $x$ and $y$ and output variables $u$ and $v$, what is the relationship between the input and output pdfs in the various cases for the two cases $b \le T$ and $b \gt T$ for the following simple (not meant to actually model anything) example that still shows some of the issues? ~~~~ a := 2 * x b := a + y c := min(b,T) d := c / b u := a * d f := y * d v := 2 * f ~~~~ I was working towards an idea, hope to get back to it at some point...
• Options
10.

Hi David,

Tim van B. has set up an account and access rights for me on the code.google repo.

Is the best thing to start version control for your software in some form such as DSE-0.0.1 for your initial version and then DSE-0.0.2 for the upgrade or just merge them together?

At least author details need to be in the README. Do you want to add copyright and licence info to this. I see the GPL licence mentioned on the google site.

I don't know whether there's an azimuth poliicy on this? I'm used to the haskell community which uses BSD and is, I think, less restrictive.

Best wishes

Comment Source:Hi David, Tim van B. has set up an account and access rights for me on the code.google repo. Is the best thing to start version control for your software in some form such as DSE-0.0.1 for your initial version and then DSE-0.0.2 for the upgrade or just merge them together? At least author details need to be in the README. Do you want to add copyright and licence info to this. I see the GPL licence mentioned on the google site. I don't know whether there's an azimuth poliicy on this? I'm used to the haskell community which uses BSD and is, I think, less restrictive. Best wishes
• Options
11.
edited March 2012

FWIW, the new implementation I'm thinking about will be very different so it won't so much be an "new version" as a "new approach". If I ever get anywhere, I'll add it sa something like new directory "DSE-using-transition-estimation". (I don't imagine snappy names will matter much for Azimuth.)

Regarding licences, my personal preference for library code is LGPL. (For non-software people: the three big licence choices are:

• BSD: anyone can use and modify the code any way they want, including making changes they keep to themselves.

• GPL: anyone can use the and modify the code in any combined program, but they have to make modifications to all parts of the program available to anyone who wants them on the same terms.

• LGPL (Lesser GPL): anyone can call the library code from any combined program. The library can be modified, but those modifications have to be made available. However this obligation doesn't extend to code in the combined program outside the library.

).

However, the DSE code is templated inline C++, which to my limited understanding doesn't really allow an LGPL licence (since there's not really any way to create a program where the library remains a distinctly separate block of object code), although I'm not an expert on this (and have no burning desire to become one...). So I'm happy to make the DSE code BSD licenced, providing no-one more active in the code project says this will cause problems (say, code with different licences in the same repository not being possible).

Certainly feel free to add my name and email to any others added to the README, and clarify the licence once it's clear what the best licence is.

Comment Source:FWIW, the new implementation I'm thinking about will be very different so it won't so much be an "new version" as a "new approach". If I ever get anywhere, I'll add it sa something like new directory "DSE-using-transition-estimation". (I don't imagine snappy names will matter much for Azimuth.) Regarding licences, my **_personal_** preference for library code is LGPL. (For non-software people: the three big licence choices are: * BSD: anyone can use and modify the code any way they want, including making changes they keep to themselves. * GPL: anyone can use the and modify the code in any combined program, but they have to make modifications _to all parts of the program_ available to anyone who wants them on the same terms. * LGPL (Lesser GPL): anyone can call the library code from any combined program. The library can be modified, but those modifications have to be made available. However this obligation doesn't extend to code in the combined program _outside the library_. ). However, the DSE code is templated inline C++, which to my limited understanding doesn't really allow an LGPL licence (since there's not really any way to create a program where the library remains a distinctly separate block of object code), although I'm not an expert on this (and have no burning desire to become one...). So I'm happy to make the DSE code BSD licenced, providing no-one more active in the code project says this will cause problems (say, code with different licences in the same repository not being possible). Certainly feel free to add my name and email to any others added to the README, and clarify the licence once it's clear what the best licence is.
• Options
12.

Hi David,

I too care nothing for copyrights and licenses. I didn't add any information at all to the the README, not even your authorship, expecting to edit it on the site:. As our "band of 3" could no longer build your source might it be best to just merge the diffs from this archive? I have no idea how to do this but will keep reading.

BTW Have you come across Jun S. Liu Monte Carlo Strategies in Scientfic Computing, Springer 2001. It has some interesting cases where Markov chains are not the best tool.

Comment Source:Hi David, I only seem to receive notifications of some discussion posts so I've only just found your reply. I know nothing about code.google.com. I uploaded DSE.zip ("to upload go to the download tab" or some such) with the title DSE. It appears under downloads. It said I could upload compressed files so I did but can find no information about unzipping an archive on the site. Do I have to create a local svn repo with the same structure and then sink it to the project? I too care nothing for copyrights and licenses. I didn't add any information at all to the the README, not even your authorship, expecting to edit it on the site:. As our "band of 3" could no longer build your source might it be best to just merge the diffs from this archive? I have no idea how to do this but will keep reading. BTW Have you come across Jun S. Liu Monte Carlo Strategies in Scientfic Computing, Springer 2001. It has some interesting cases where Markov chains are not the best tool.
• Options
13.

I recall that when I first creaed my extension I "checked out" a full working svn repository of all the code on the Azimuth project (I think using the instructions on this page ), then created a new subdirectory and copied over and svn add'ed my files and then did an svn checkin. There's definitely a source control system on googlecode, but I don't know much about it. In addition the web browser seems to claim there aren't any files in the directory, but I've no idea why. Added to that is the complication that at the time I had a networked home Linux machine so running svn commands wasn't a problem; currently I'm stuck using internet cafe machines (eg, now) so it's essentially impossible to work using svn. Maybe Tim, or someone else who's reading who's active with a different googlecode project, can shed some light on things.

There is actually a more methodical development history in git on my local machine/backups (I was planning on using git for "real development" because it was designed to encourage more granular check-ins as you develop to local only branches and then dumping "releases" into the google-code svn.) Should I ever get the time and resources to do regular development on Azimuth stuff, I'm thinking of that I'll probably try and make detailed "in progress" development visible by hosting a repository on github, but again do "release dumps" to the googlecode svn repo. It's a bit of a dilemma: on the one hand the Azimuth googlecode pages present a strong unifying and "advertising" force, but svn is such a bad fit for decentralised development that it's probably worth the hassle of maintaining an separate "in progress" tree in git.

If you can figure out any way to "import" improvements to the code, go for it even if it doesn't look like the "offical" way to do it. And as I haven't said it, thanks for your interest and work taking this stuff forward.

I haven't read the Liu book, but it sounds interesting. I can imagine that there are lots of ways of modelling ideas which aren't Markov chains/processes.

Comment Source:I recall that when I first creaed my extension I "checked out" a full working svn repository of all the code on the Azimuth project (I think using the instructions on [this page](http://code.google.com/p/azimuthproject/source/checkout) ), then created a new subdirectory and copied over and svn add'ed my files and then did an svn checkin. There's definitely a source control system on googlecode, but I don't know much about it. In addition the web browser seems to claim there aren't any files in the directory, but I've no idea why. Added to that is the complication that at the time I had a networked home Linux machine so running svn commands wasn't a problem; currently I'm stuck using internet cafe machines (eg, now) so it's essentially impossible to work using svn. Maybe Tim, or someone else who's reading who's active with a different googlecode project, can shed some light on things. There is actually a more methodical development history in git on my local machine/backups (I was planning on using git for "real development" because it was designed to encourage more granular check-ins as you develop to local only branches and then dumping "releases" into the google-code svn.) Should I ever get the time and resources to do regular development on Azimuth stuff, I'm thinking of that I'll probably try and make detailed "in progress" development visible by hosting a repository on github, but again do "release dumps" to the googlecode svn repo. It's a bit of a dilemma: on the one hand the Azimuth googlecode pages present a strong unifying and "advertising" force, but svn is such a bad fit for decentralised development that it's probably worth the hassle of maintaining an separate "in progress" tree in git. If you can figure out any way to "import" improvements to the code, go for it even if it doesn't look like the "offical" way to do it. And as I haven't said it, thanks for your interest and work taking this stuff forward. I haven't read the Liu book, but it sounds interesting. I can imagine that there are lots of ways of modelling ideas which aren't Markov chains/processes.
• Options
14.

Thanks for the prompt reply. Again i didn't get any email notification of your post. I haven' t used svn for a long time. I'd better read up on if and how I can do partial checkins and checkouts. Some light from Tim van B. or somebody would be most welcome. Interworking svn and git sounds like it might be a complete nightmare.

I meant Markov chains only in the context of Monte-Carlo methods and only mentioned it because I didn't know there were non-Markov Monte-Carlo methods. The Chiu book has 10 lines on Euler-Langevin moves for hybrid Monte Carlo methods. He points out that a Langevin update is equivalent to a one-step hybrid Monte Carlo.

Comment Source:Thanks for the prompt reply. Again i didn't get any email notification of your post. I haven' t used svn for a long time. I'd better read up on if and how I can do partial checkins and checkouts. Some light from Tim van B. or somebody would be most welcome. Interworking svn and git sounds like it might be a complete nightmare. I meant Markov chains only in the context of Monte-Carlo methods and only mentioned it because I didn't know there were non-Markov Monte-Carlo methods. The Chiu book has 10 lines on Euler-Langevin moves for hybrid Monte Carlo methods. He points out that a Langevin update is equivalent to a one-step hybrid Monte Carlo.
• Options
15.

Hi Jim,

I don't know if anyone's mentioned it, but regarding email notifications you probably need to ask about it on a thread in "Technical" since Andrew Stacey only generally reads that classification.

Regarding the Monte-Carlo stuff, there's at least two ways in which Markov Chain is used.

1. The common one, called Markov Chain Monte Carlo (MCMC) might be called in detail "Monte Carlo sampling using Markov chains in the implementation", and there's no need for whatever model you're trying to do Monte Carlo sampling on to be any kind of Markov chain.

2. You can have a model which is actually a Markov Chain, and to get some insight about it you can try and use Monte Carlo sampling. (Indeed you could use MCMC to do your Monte Carlo sampling on your Markov Chain.)

It's this second case that I've been thinking about, because it's actually really quite hard to come up with a well-motivated model which isn't Markov to some small order, ie, of where "direct influence" from the past is limited to a small number of immediately previous timestep.

But there are definitely more general processes going on when you look at the physical world in much greater detail: for example, initially it looks like genetic changes through sexual combination is a Markov process, since you've got both parents DNA interacting but no direct involvement of the grandparents DNA, etc. But apparently (not an expert) there's mitochondrial DNA influences and other epigenetic phenomena that provide a certain degree of influence from further in the past. Likewise, in fully realistic population modelling there are non-Markov influences. I'm just experimenting, seeing if there's still interesting empirical stuff to find out when the processes are Markov but there's lots of non-classical-analysis-amenable functions being used.

Comment Source:Hi Jim, I don't know if anyone's mentioned it, but regarding email notifications you probably need to ask about it on a thread in "Technical" since Andrew Stacey only generally reads that classification. Regarding the Monte-Carlo stuff, there's at least two ways in which Markov Chain is used. 1. The common one, called Markov Chain Monte Carlo (MCMC) might be called in detail "Monte Carlo sampling using Markov chains in the implementation", and there's no need for whatever model you're trying to do Monte Carlo sampling on to be any kind of Markov chain. 2. You can have a model which is actually a Markov Chain, and to get some insight about it you can try and use Monte Carlo sampling. (Indeed you could use MCMC to do your Monte Carlo sampling on your Markov Chain.) It's this second case that I've been thinking about, because it's actually really quite hard to come up with a well-motivated model which isn't Markov to some small order, ie, of where "direct influence" from the past is limited to a small number of immediately previous timestep. But there are definitely more general processes going on when you look at the physical world in much greater detail: for example, initially it looks like genetic changes through sexual combination is a Markov process, since you've got both parents DNA interacting but no direct involvement of the grandparents DNA, etc. But apparently (not an expert) there's mitochondrial DNA influences and other epigenetic phenomena that provide a certain degree of influence from further in the past. Likewise, in fully realistic population modelling there are non-Markov influences. I'm just experimenting, seeing if there's still interesting empirical stuff to find out when the processes are Markov but there's lots of non-classical-analysis-amenable functions being used.
• Options
16.
edited March 2012

David wrote:

there's no need for whatever model you're trying to do Monte Carlo sampling on to be any kind of Markov chain.

Yes. That's what I didn't know but found out from the Liu book.

the processes are Markov but there's lots of non-classical-analysis-amenable functions being used.

Thanks for the tip about Technical - I thought there must be such a page somewhere.

Comment Source:David wrote: > there's no need for whatever model you're trying to do Monte Carlo sampling on to be any kind of Markov chain. Yes. That's what I didn't know but found out from the Liu book. > the processes are Markov but there's lots of non-classical-analysis-amenable functions being used. That sounds difficult but nonetheless I'm looking forward to your further thoughts about this spec. Thanks for the tip about Technical - I thought there must be such a page somewhere.
• Options
17.

By the way, Jim, I changed your quotes from

<pre>this</pre>

to the more desirable Markdown syntax

> this

The former produces

this

while the latter produces

this

No big deal, but at least the 'good' way takes fewer keystrokes!

Comment Source:By the way, Jim, I changed your quotes from <pre>this</pre> to the more desirable Markdown syntax > this The former produces <pre>this</pre> while the latter produces > this No big deal, but at least the 'good' way takes fewer keystrokes!
• Options
18.

Thanks John. Instiki is still high on my ignorance list.

Comment Source:Thanks John. Instiki is still high on my ignorance list.