Implementations of Markov chain Monte Carlo methods?

1,945 views
Skip to first unread message

Douglas Bates

unread,
Oct 10, 2012, 10:58:11 AM10/10/12
to juli...@googlegroups.com
There are many McMC stand-alone implementations with links to R; Bugs/OpenBugs (http://mathstat.helsinki.fi/openbugs/) with the BRugs interface, JAGS (mcmc-jags.sourceforge.net) with rjags, and now Stan (mc-stan,org) with the rstan interface.

It seems to me that all these implementations are based on a parser that takes a model specification in a Bugs-like language and translates it into another language or calls in another language to create the actual sampler.  The actual sampler is implemented in a compiled language for performance because McMC is a compute-intensive operation.  This translation is most evident in Stan where the model specification in the stan language is translated into C++ code that is compiled and accessed  from R through the Rcpp interface.

This all means that the painful two-language with interfaces approach to getting performance in dynamic languages like R and Matlab becomes a three-language with interfaces approach where the model specification language is translated to a static compiled language that is linked to a dynamic language.

A Julia implementation of such a system would, I believe, be much less painful.  I still don't know enough about the mechanics of languages like Bugs to concoct samplers (John Myles White undoubtably knows more) but I do know a bit about evaluating pdf's, pmf's, cdf's, etc. for distributions and would be happy to work on making the Distributions module more useful for these purposes.

What I would like to see is an informal working group, or perhaps an organization on github, devoted to creating Julia tools for McMC implementation.  In other words, I think that it would be better to create a collection of tools that could be easily assembled to create a sampler rather than having a closed system like Bugs, which to me seems like old-style "statistical packages" such as SAS and SPSS. 

I think McMC could be a "killer app" for Julia in the statistical computing world.

Chris DuBois

unread,
Oct 10, 2012, 12:36:25 PM10/10/12
to juli...@googlegroups.com
Hi Douglas,

I agree that Julia is well suited for MCMC.  A few months ago I translated a few samplers from Radford Neal's GRIMS R package.  They aren't heavily optimized or tested (yet), but nonetheless I've found them useful.  My motivation for this project sounds much like what you describe: a collection of tools that could be easily assembled to create a sampler.  It is, however, very distant from BUGS/JAGS/Stan approaches.  

I would be very interested in a working group (and an associated github organization) on this topic, and I know several others that would be as well.

Chris

--
 
 
 

John Myles White

unread,
Oct 10, 2012, 1:41:48 PM10/10/12
to juli...@googlegroups.com
I'll chime in more on this later today, but wanted to say a few things.

First off, I've used Chris's code before and think it could easily be the basis for the samplers we'd use in an MCMC system.

That said, most of the substance of a system like BUGS/JAGS/Stan lies in building an expert system that has domain knowledge about how to handle specific models. I'll track down links, but I've been told that Stan actually lags behind JAGS in some standard models for which this domain knowledge is missing, even though the NUTS sampler at the core of Stan can be substantially more efficient than the non-gradient samplers used in BUGS/JAGS when they're applied appropriately. It would be good to talk with Martyn Plummer about JAGS before embarking on a project to build something similar in Julia.

I'm happy to participate in a working group on this topic, although I'm badly overcommitted with existing projects and will not be able to much coding.

Maybe as a start, we should agree on a language w'ed like to implement and get some simple examples working. For instance, the simplest JAGS code I start with tends to be inference for the mean of a Gaussian with known variance of 1. In JAGS, that looks like

model
{
for (i in 1:N)
{
x[i] ~ dnorm(mu, 1)
}

mu ~ dnorm(0, 0.001)
}

A JAGS system could handle this model specification (given some data for x of length N) in many ways. It could attempt to run Metropolis-Hasting and tune a proposal distribution. It could use a slice sampler. It could exploit knowledge about conjugacy to directly sample from the posterior. Building a system that's fast relies upon knowing which of these strategies to use.

 -- John

--
 
 
 

John Myles White

unread,
Oct 11, 2012, 2:32:43 PM10/11/12
to juli...@googlegroups.com
More thorough follow-up. Hopefully this isn't too cryptic. Please let me know what I leave unclear.

(1) I really like the idea of pushing on Julia as a tool for MCMC, but would like to encourage us to start small. A full MCMC system like JAGS or Stan requires a team whose job is exclusively to maintain the system. For example, Stan (whose sole purpose is to be faster than JAGS) occasionally discovers that JAGS has a clever trick for special classes of models that lets JAGS beat out Stan. See https://groups.google.com/forum/#!topic/stan-users/QDumPPbRa4Q/discussion for one example. Maintaining a system that's competitive with JAGS/Stan will be a major undertaking on the same scale as building Stan, which had three full time developers who were all postdocs in Gelman's group working on the project for more than one year.

(2) One way we could start small is to focus on translating a JAGS-like syntax into Julia code that uses the samplers in Distributions. (Or, as the StrangeLoop crowd would say, we need a JAGS-to-Julia transpiler.) I think this is promising because it seems like we could very slowly build up a mini-language that can be translated into very specific Julia code. For example, we could just implement the standard conjugate pairs and provide a brief language for working with those that is translated into Julia. I would really like something like that, because it would make the system much more transparent than JAGS, which is very hard to debug. If a modeling language were translated into Julia, we would not have to worry as much about performance because the end-user could customize the produced code when they realize that the translator isn't exploiting domain knowledge. The problem with JAGS/Stan is that the efficiency they achieve is largely a black-box, which makes it very hard for outsiders to contribute to the project. In other words, we could try to do better than JAGS/Stan by following Julia's strategy of doing everything in Julia, rather than dropping to a C-language for speed.

(3) Before we could even start doing (2), we'll need two things: a nice parsing library and a nice automatic differentiation library. Perhaps those should be our original focus? I know there's work on automatic differentiation already. I'm less aware of parsing, although it's come up in the context of Formula syntax for GLM's in JuliaData discussions. Maybe thinking more about that is the best place to start, especially because I have so little knowledge of how to write a decent parser.

(4) I think BUGS is much less like SAS/SPSS than it might seem. BUGS is a full programming language (it might actually be Turing complete) that allows one to implement essentially any model imaginable. It's just horribly slow and clunky when you start to write models that it wasn't designed to handle. Mixture models, for example, can be very hard to express in BUGS. Stan is, linguistically, as expressive as BUGS, except that the Hamiltonian MCMC tricks that power it only apply to models with continuous variables, because the system increases statistical efficiency by using the gradient of the log posterior of a model. In short, it's basically the same language, but translates continuous models into better algorithms for sampling the model parameters.

MCMC-style computations are what drew me to Julia originally, so I hope we can find useful places for abstraction here.

-- John
> --
>
>
>

Andrei de Araújo Formiga

unread,
Oct 11, 2012, 3:04:12 PM10/11/12
to juli...@googlegroups.com
I've been thinking about this in similar lines recently. I actually
thought about the possibility of exposing different levels of
abstraction, a higher level that could be similar to JAGS/BUGS, a
"middle" that could be defined with operators/macros in Julia itself
and a lower level composed of the samplers. Maybe it could be
interesting to use the same higher-level models with different
"backends" to run them, maybe even calling Stan from Julia, for
example.

In any way, I agree with this, and it should definitely start small.

2012/10/11 John Myles White <johnmyl...@gmail.com>:
> --
>
>
>

John Myles White

unread,
Oct 11, 2012, 5:06:30 PM10/11/12
to juli...@googlegroups.com
The other small start is to wrap JAGS or Stan in Julia. From what I saw, that's not so small.

-- John
> --
>
>
>

Andrei de Araújo Formiga

unread,
Oct 11, 2012, 5:16:32 PM10/11/12
to juli...@googlegroups.com
Indeed, both are in C++ and at least in Stan case it doesn't seem to
have a simple C interface. The R bindings use Rcpp as far as I know.
> --
>
>
>

Ian Fiske

unread,
Oct 11, 2012, 10:27:03 PM10/11/12
to juli...@googlegroups.com
+1 for automatic differentiation. That would also come in handy for loads of other optimization problems. As far as I can tell there has been some existing work for forward mode but not reverse mode. Of course reverse mode is the killer approach for optimization although harder to implement.

sth4nth

unread,
Oct 12, 2012, 1:07:02 AM10/12/12
to juli...@googlegroups.com
I've thinking about this for a while. Since julia is a powerful FP style language, we might should leverage the DSL ability of Julia to define the interface for Bayesian inference. For example, the Church language (https://projects.csail.mit.edu/church/wiki/Computation_in_Church), which is a variant of lisp, incorporate the probabilistic modelling ability into its syntax. Also there is infer.net fun project, which is based F# to do similar things.

Besides MC based methods, there are also other optimization based inference technique such as mean filed and belief propagation algorithm also can do the job. We should separate the inference engineer and modelling interface. The modelling interface is to define the problem structure (a.k.a the Graphical model), the engine is to do the inference job. Which engine to use is up to the user. 

In my opinion, we should not adopt the R still modelling interface, since Julia is far more powerful language, we should leverage macro to define a better DSL for probabilistic inference like Church and Fun.

Here are some material for probabilistic DSL programming:

Best,
Mo

Andrei Formiga於 2012年10月12日星期五UTC+8上午3時04分19秒寫道:

Adrian Cuthbertson

unread,
Oct 12, 2012, 1:57:26 AM10/12/12
to juli...@googlegroups.com
It seems the threads spread far, wide and deep :). I'm just embarking
on a learning curve with MCMC methods as a focus, so this initiative
will be very interesting to follow and participate in where I can.

Regards, - Adrian.
> --
>
>
>

John Myles White

unread,
Oct 13, 2012, 5:52:12 PM10/13/12
to juli...@googlegroups.com
I have to confess that I don't know what reverse mode means here.

-- John

On Oct 11, 2012, at 10:27 PM, Ian Fiske wrote:

> +1 for automatic differentiation. That would also come in handy for loads of other optimization problems. As far as I can tell there has been some existing work for forward mode but not reverse mode. Of course reverse mode is the killer approach for optimization although harder to implement.
>
> --
>
>
>

Stefan Karpinski

unread,
Oct 13, 2012, 5:59:50 PM10/13/12
to juli...@googlegroups.com
The separation is definitely the way to go. Was going to write that myself earlier but, in any case, yes!
--
 
 
 

Andrei de Araújo Formiga

unread,
Oct 13, 2012, 7:19:07 PM10/13/12
to juli...@googlegroups.com
It's basically the order the differentials are evaluated in the chain
rule. Reverse-mode tends to be better for objective functions in
optimization.

2012/10/13 John Myles White <johnmyl...@gmail.com>:
> --
>
>
>

Ian Fiske

unread,
Oct 13, 2012, 7:32:23 PM10/13/12
to juli...@googlegroups.com
Yes, an AD system for statistical optimization work needs reverse mode to handle models with many parameters.  See for example ADMB (http://admb-project.org/) and the cited paper (http://tandfonline.com/doi/abs/10.1080/10556788.2011.597854).

Of course ADMB implements one of the many algorithms for reverse mode and I don't know what approach would be best for Julia.  There are a couple of functional approaches that might be suitable (scheme: http://www.bcl.hamilton.ie/~qobi/stalingrad/ and haskell:  http://hackage.haskell.org/cgi-bin/hackage-scripts/package/ad), but I'm not sure if the pure functional approach will have the performance found in the C++ or Fortran versions.  There has also been work on this for Matlab which might be relevant to Julia: https://dspace.lib.cranfield.ac.uk/bitstream/1826/4356/1/ForthICCS2010.pdf.

Stefan Karpinski

unread,
Oct 13, 2012, 8:20:55 PM10/13/12
to juli...@googlegroups.com
These are great resources. Thanks!
--
 
 
 

Andrei de Araújo Formiga

unread,
Oct 13, 2012, 9:19:08 PM10/13/12
to juli...@googlegroups.com
Is it possible to access the Julia code/AST for a given function? This
would come in handy to implement automatic differentiation for any
given function. Failing that, maybe a macro that wraps a given code
block in a context where the operators are redefined to calculate the
differentiation, but this means the writer of the function to be
differentiated must define it using the macro instead of the usual
function definition in Julia.

2012/10/13 Stefan Karpinski <stefan.k...@gmail.com>:
> --
>
>
>

Patrick O'Leary

unread,
Oct 14, 2012, 1:08:54 AM10/14/12
to juli...@googlegroups.com
On Saturday, October 13, 2012 8:19:09 PM UTC-5, Andrei Formiga wrote:
Is it possible to access the Julia code/AST for a given function? This
would come in handy to implement automatic differentiation for any
given function. Failing that, maybe a macro that wraps a given code
block in a context where the operators are redefined to calculate the
differentiation, but this means the writer of the function to be
differentiated must define it using the macro instead of the usual
function definition in Julia.

I've figured it out for anonymous functions (f.code.ast) but haven't figured it out in the case of generic functions.

Kevin Squire

unread,
Oct 14, 2012, 1:03:10 PM10/14/12
to juli...@googlegroups.com
Perhaps reverse AD could be implemented by wrapping a block of code in a manner similar to how the profiler works, e.g., something like

@ad begin
include("math_fns.jl")

def some_func(theta)
   sin(theta)^2 + cos(theta)^2
end

end   # @ad begin

That way, even functions which are not originally defined using the AD macro could be differentiated.  Some cleverness would probably be needed to deal with functions which shouldn't be differentiated or those which call C code.

Kevin

On Saturday, October 13, 2012 8:19:09 PM UTC-5, Andrei Formiga wrote:

Simon Byrne

unread,
Oct 15, 2012, 3:59:12 PM10/15/12
to juli...@googlegroups.com
I think this is a great idea: using the one language for everything is bound to make things easier.

I've had a bash at implementing a bugs-type interpreter using a macro here:

It's pretty rudimentary, and doesn't do anything clever (it just does slice sampling, using Chris DuBois's code, on each variable in turn). But it works, at least as a proof of concept. 

Simon

John Myles White

unread,
Oct 16, 2012, 10:57:23 AM10/16/12
to juli...@googlegroups.com
Very cool!

I'd like to push for us to keep inference and model definition separate. The virtue of BUGS-systems is that you don't need to know what slice-sampling is to be able to use it. I'd like to see something like:

model = quote

for i in 1:N
x[i] ~ Normal(mu, sigma)
end

mu ~ Normal(0, 1000.0)
sigma = 1.0

end

data = {:x => x}

compile(model, data)

-- John
> --
>
>
>

Simon Byrne

unread,
Oct 16, 2012, 11:35:37 AM10/16/12
to juli...@googlegroups.com

On Tuesday, 16 October 2012 15:57:26 UTC+1, John Myles White wrote:
I'd like to push for us to keep inference and model definition separate. The virtue of BUGS-systems is that you don't need to know what slice-sampling is to be able to use it.

I agree entirely. One thing I would like would be an additional interface somewhere in the middle, that allows the user to specify the samplers to use on each variable (or set of variables for block updating), but uses the model definition to figure out all the exact details (so they don't need to derive all the equations).

Simon

Andrei de Araújo Formiga

unread,
Oct 16, 2012, 11:59:29 AM10/16/12
to juli...@googlegroups.com
That's what I've been thinking about too, as I said somewhere back in
this thread. I thought about the three levels as:

- Higher level is the model specification in a language similar to JAGS/BUGS
- Middle level is an embedded DSL (domain-specific language) in Julia,
possibly using macros, where the user can specify the computation in
greater detail (samplers, etc)
- Lower level would be the samplers/inference engines themselves,
basically the raw MCMC machinery (plus maybe other kinds of inference
engine, I don't know if something using variational inference would be
feasible)

This way advances in the inference engines could be decoupled from
high-level use, but users willing to have more control would get it in
the middle layer. Julia is powerful enough to define the embedded DSL
in the middle so that it works well and is nice to use.

2012/10/16 Simon Byrne <simon...@gmail.com>:
> --
>
>
>

John Myles White

unread,
Oct 16, 2012, 12:41:11 PM10/16/12
to juli...@googlegroups.com
I'm in total agreement here. Let's start to refine those levels more.

To help us, I've set some infrastructure up.

(1) I've just set up a Google Group for us to continue the discussion. The address is julia...@googlegroups.com

(2) I've set up a GitHub repo for us to start to refine a plan and some code examples. The URL is https://github.com/johnmyleswhite/bugs.jl

(3) I've used the GitHub repo's wiki to write some very simple examples that are almost already Julia expressions. If we get an enough examples in place, I think it will be much easier to actually plan out the rest of our work: https://github.com/johnmyleswhite/bugs.jl/wiki/Proposed-DSL

-- John
> --
>
>
>

John Myles White

unread,
Oct 16, 2012, 1:16:11 PM10/16/12
to juli...@googlegroups.com
In case it's not clear where the page for the mailing list is, this is the URL:


 -- John

On Oct 16, 2012, at 11:59 AM, Andrei de Araújo Formiga wrote:

--




Viral Shah

unread,
Apr 10, 2013, 11:44:18 PM4/10/13
to juli...@googlegroups.com, julia...@googlegroups.com
I just stumbled upon some analysis of Stan that Stefan had done a while back. Given that it is C++ templated code, it is not convenient to call from julia. However, Stefan's analysis may help convince someone to either translate or re-implement these methods in Julia:

Looking through the Stan code, the project includes:
  • IO libraries
  • memory manager
  • math libraries
  • matrix implementation
  • optimization algorithms
  • C++ template metaprogramming utilities
  • definitions of standard probability distributions
  • a parser for the custom model language
  • MCMC code
The actual MCMC code seems to be approximately 4000 lines out of a total of about 37000 lines of code.

-viral

Rahul Dave

unread,
Apr 11, 2013, 10:27:30 AM4/11/13
to julia...@googlegroups.com, juli...@googlegroups.com
Being about neck deep in HMC right now, I suspect that the hardest parts to port from Stan are the optimization and tuning parts...In other words the 4000 lines are complex ones, supporting both standard HMC and NUTS..

But you are entirely right...it would be a killer app. And the constructs of Julia seem very suitable.. If someone hasnt done it already (or is doing it) would be quite happy to work on parts of this after the academic year ends (1st week of may!).

Chris has a HMC sampler based on Radford Neils paper's R code, perhaps he could comment on a direction forward?
Rahul
-- 
Rahul Dave
Sent with Sparrow

--
You received this message because you are subscribed to the Google Groups "julia-stats" group.
To unsubscribe from this group and stop receiving emails from it, send an email to julia-stats...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

Viral Shah

unread,
Apr 11, 2013, 10:56:47 AM4/11/13
to juli...@googlegroups.com, julia...@googlegroups.com
Undoubtedly, I did not mean to say that it would be simple. I just meant to point out that the effort may be lesser than what it may appear at first glance. One of the things that I personally hope Julia will enable is that such projects in the future can focus on the problem at hand, rather than on all the tooling and plumbing. I know we have a lot to do.

In my opinion, the MathProg implementation by Miles and Iain is an encouraging example of this in linear programming.

-viral

Chris DuBois

unread,
Apr 11, 2013, 11:30:40 AM4/11/13
to juli...@googlegroups.com, julia...@googlegroups.com
Glancing at Dahua's slides, it looks like this is an effort to allow for general inference routines on graphical models (e.g., belief propagation or any other message-passing-based approach). (Think Koller's Probabilistic Graphical Models book.) 

I would check out SimpleMCMC.jl as a starting point for writing your own NUTS, or look at Matt Hoffman's Matlab code.

Looking back at this thread, I see a lot of talk about automatic differentiation. Does anybody know what the current state is? 

Theodore Papamarkou

unread,
Apr 11, 2013, 11:49:56 AM4/11/13
to juli...@googlegroups.com, julia...@googlegroups.com
Hi Chris, hi all,

This is the first time I came across this post re MCMC, and it is very pleasing that several "Julia people" have expressed interest in MCMC coding. With the danger of leaving out a package (if I do so, please correct me), here is the list of simulation or MCMC related Julia packages at the moment:

* MCMC,
* simpleMCMC,
* SimJulia,
* GeometricMCMC.

As for automatic differentiation, I am currently doing some work to extend the algorithms of the GeometricMCMC package. A very useful introduction to automatic differentiation is the following master thesis by Lium Torbjorn, which was mentioned to me by a colleague of mine:


A more comprehensive (and rather authoritative) reference to automatic differentiation is this book:


If you are interested in following up with more recent advances in AD (and finding more references), this is perhaps the most popular website:


One more thing, MCMC research advances in such fast pace that there are already many new methodologies that have not been coded yet in one of the above packages. For example, there have been publications on HMC on Hilbert spaces, geodesic Monte Carlo, and quantum Monte Carlo such as variational and diffusion Monte Carlo methods.

Best,
Theo

Chris DuBois

unread,
Apr 11, 2013, 11:54:12 AM4/11/13
to julia...@googlegroups.com, juli...@googlegroups.com
Thanks Theo! These are great resources! 

Could you expand a little on the role of automatic differentiation for your GeometricMCMC package?

Theodore Papamarkou

unread,
Apr 11, 2013, 12:14:13 PM4/11/13
to juli...@googlegroups.com, julia...@googlegroups.com
Yes, of course Chris, happy to share thoughts. So basically my motivation is simply the fact that the gradient of the target (as well as the metric tensor in the case of geometric MCMC) are not known in closed form in many cases. Muti-dimensional problems for example. Another example is that of systems of differential equations, where the involved sensitivities are not soluble analytically. Even when it is possible to derive exact formulae for the needed derivatives, Jacobians and Hessians, this is a rather cumbersome task, so even then it is prefereable from the suer end to rely on AD. In a few words, AD is the preferable way to employ within MCMC, unless we are talking about simple models (such as the logit and probit models I added in GeometricMCMC).

That's the motivation. As for the implementation, I am currently cheating (in the well-meaning way :)). I downloaded John's Calculus package and the simpleMCMC Julia code and read the basics from the above master thesis in order to implement forward AD in the case of the logit and probit models (to make sure that I get identical results to the ones I get via the closed forms). I am also pondering whether I should buy the book I mentioned, to check what it says about Jacobians and Hessians, although the same author published a more recent book (2012) on AD, which may be more geared towards optimization rather than simple simulation using AD...

I think we should all try to extend our little MCMC packages to use AD, if you agree?

Chris DuBois

unread,
Apr 11, 2013, 12:26:03 PM4/11/13
to juli...@googlegroups.com, julia...@googlegroups.com
I am on board with the motivation! I would like to incorporate it into MCMC.jl soon. 

It would be nice if all the MCMC packages could take advantage of a single AD framework. Is this a realistic scenario?

Theodore Papamarkou

unread,
Apr 11, 2013, 12:32:07 PM4/11/13
to juli...@googlegroups.com, julia...@googlegroups.com
My view is that a Symbolic package and an AD (automatic differentiation) package may be of use in many scenarios, so it would be practical to have a central implementation. I don't want to be territorial, so I think that Jeff, Stefan, Viral et al are better suited answering this question (and more experienced than me too), I merely expressed my thoughts :) So if it is decided to have one package for AD, I am more than happy to work together. Let's see who else is interested. If we don't hear from many other people, we could look into AD together.

P.S. 1: AD does not involve truncation errors, that's one more motivation in comparison with numerical differentiation.
P.S. 2: I forgot to mention tempering/population MCMC in the Monte Carlo methods that need to be implemented.

Kevin Squire

unread,
Apr 11, 2013, 1:13:27 PM4/11/13
to julia...@googlegroups.com, juli...@googlegroups.com

Over a year ago, Jonas Rauch created a nice forward AD implementation using dual numbers:


I've played around with it a little, and updated it a few months ago to work with newer versions of Julia.  I was contemplating contacting Jonas and turning it into a package, but as it goes with these things, I got busy with other things.  I'll see if I can dig it out and get it working again.

AD was also discussed previously on julia-dev (https://groups.google.com/d/topic/julia-dev/GId3CTNoJnw/discussion), and Miles Lubin, at least, expressed some interest.

For reverse AD, the lisp by Jeffrey Siskind, in particular (http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.147.3715), might be a good target to translate in to julia, although the paper is a bit dense to me and my lisp isn't stellar.  But I also really like the references Theodore mentioned as well, especially the Griewank book.  For those at universities with SIAM subscriptions, the full version is available as pdf chapters: http://epubs.siam.org/doi/book/10.1137/1.9780898717761.

Anyway, I'm interested and inclined to help, although I'm not sure how much time I can commit.  Please keep me in the loop.

Cheers!
   Kevin

Theodore Papamarkou

unread,
Apr 11, 2013, 1:34:24 PM4/11/13
to juli...@googlegroups.com, julia...@googlegroups.com
Thanks Kevin! It would be very helpful and time saving if you manage to find your update of the ad.jl file! The one you sent already seems easy to follow through, which is good.

Oh, I should had checked the archive, I missed the previous AD thread.

I guess if it's several of us interested in AD, we could split the workload and each of us won't have to spend an immense amount of time on a potential package. Let's see if John for instance has done some coding too, and if Miles is also still interested... then we could start from the available code and each of us could undertake small tasks, without any pressure...

Chris, you and I, it's already three of us interested in doing a bit of work on AD.

Theo

John Myles White

unread,
Apr 11, 2013, 2:06:22 PM4/11/13
to juli...@googlegroups.com
I haven't done any work on AD so far. I'd be happy to contribute over the summer, but won't have time to work on anything till then. I'm already beyond my capacity with the packages I'm currently managing.

 -- John

Theodore Papamarkou

unread,
Apr 11, 2013, 2:42:04 PM4/11/13
to juli...@googlegroups.com
Thanks for letting us know John. We could get this going for now by extending a bit some of the available code so that we have some elementary AD for the needs of MCMC, if Chris and Kevin agree. We could then expand the AD package over the summer, when you will be available.

Rahul Dave

unread,
Apr 11, 2013, 3:40:26 PM4/11/13