
Hakaru: An embedded probabilistic programming language in Haskell - wcbeard10
http://indiana.edu/~ppaml/
======
PieSquared
The last example in the more detailed notebook [0] linked from that page is
also pretty cool, especially with the graphs. If you're familiar with Haskell
or other similar languages, the code is fairly easy to read.

[0]
[http://indiana.edu/~ppaml/HakaruTutorial.html](http://indiana.edu/~ppaml/HakaruTutorial.html)

------
datahipster
I'm not familiar with Haskell, but can someone provide some insight into how
this compares to PyMC or OpenBUGS?

~~~
cf
One of the authors here. In terms of expressiveness, Hakaru is much more in
the mold of something like Church, Venture, or Anglican where we can more
easily express nonparametric models. This means in the context of the model,
once a random variable is generated from a prior distribution, it might be
used as an ordinary Haskell value and be directly used to in the control-flow.
When that happens you can write models where the number of parameters changes
based on values of parameters generated earlier in the model. As a concrete
example, imagine a Bayesian Neural Network where there was a prior on how many
layers are in the neural network.

This is in contrast to something like PyMC where random variables are very
much special objects that interacted with, and making nonparametric models is
trickier.

Like PyMC, Figaro, Infer.NET and Factorie but unlike OpenBUGS this is a
library so it is easier to use a larger prediction application. We don't
support some of the optimizations that OpenBUGS can do when presented with a
model.

As another note, this is a fairly new piece of code. Unlike PyMC, BLOG, Stan,
and other probabilistic programming systems we only support Importance
Sampling and a fairly naive version of Metropolis Hastings. This is in
contrast to many of the existing solutions where you can do things like
Particle MCMC and Hamiltonian Monte Carlo. We do intend to eventually support
these inference techniques.

~~~
eru
Do you have a non-monadic, Applicative subsystem, too?

------
elwell
I love how it's titled " _Simple_ Example". I don't think I'm ready to delve
into Haskell, much less an abstraction embeeded within it. Maybe Clojure for
another 6 months and then we'll see.

~~~
eru
As someone who can Haskell, I can reassure you that the example is indeed
simple. But I understand your concern.

~~~
freyrs3
It is indeed simple, though the use of ``Data.Dynamic`` raises a few eyebrows.

~~~
cf
Most of the complexity of needing Data.Dynamic has to do with the way we store
the heterogeneous collection that is our observed data. There is a nicer way
to do this which I hope lands in a future release.

~~~
nandemo
A while ago I tried to port some of the Python code from the book Programming
Collective Intelligence to Haskell, and I got stuck on the seemingly simple
problem of reading and processing heterogenous collections (strings and
numbers).

What is the nicer way to do it?

~~~
cf
So I don't really consider myself a Haskell programmer, but the standard
advice is to think about operation you are going to perform on those strings
and numbers later, then think if there is a datatype you could create instead.

As an example, suppose I am trying to load a csv file with two fields being
strings and one being Double. A list of lists representation isn't going to
cut it. Instead I should make a Row datatype

    
    
      data Row = Row {field1 :: String, field2 :: String, field3 :: Double}
    

Then you can parse the csv file into a [Row] representation.

As an aside, if the task did involve parsing csv I suggest the cassava library
which I found out about through the amazing What I Wish I Knew When Learning
Haskell
([http://dev.stephendiehl.com/hask/](http://dev.stephendiehl.com/hask/))

