The premise of this book, and the other books in the *Think
X* series, is that if you know how to program, you can use that
skill to learn other topics.

Most books on Bayesian statistics use mathematical notation and present ideas in terms of mathematical concepts like calculus. This book uses Python code instead of math, and discrete approximations instead of continuous mathematics. As a result, what would be an integral in a math book becomes a summation, and most operations on probability distributions are simple loops.

I think this presentation is easier to understand, at least for people with programming skills. It is also more general, because when we make modeling decisions, we can choose the most appropriate model without worrying too much about whether the model lends itself to conventional analysis.

Also, it provides a smooth development path from simple examples to
real-world problems. Chapter 3 is a good example. It
starts with a simple example involving dice, one of the staples of basic
probability. From there it proceeds in small steps to the locomotive
problem, which I borrowed from Mosteller’s *Fifty Challenging
Problems in Probability with Solutions*, and from there to the
German tank problem, a famously successful application of Bayesian methods
during World War II.

Most chapters in this book are motivated by a real-world problem, so they involve some degree of modeling. Before we can apply Bayesian methods (or any other analysis), we have to make decisions about which parts of the real-world system to include in the model and which details we can abstract away.

For example, in Chapter 7, the motivating problem is to predict the winner of a hockey game. I model goal-scoring as a Poisson process, which implies that a goal is equally likely at any point in the game. That is not exactly true, but it is probably a good enough model for most purposes.

In Chapter 12 the motivating problem is interpreting SAT scores (the SAT is a standardized test used for college admissions in the United States). I start with a simple model that assumes that all SAT questions are equally difficult, but in fact the designers of the SAT deliberately include some questions that are relatively easy and some that are relatively hard. I present a second model that accounts for this aspect of the design, and show that it doesn’t have a big effect on the results after all.

I think it is important to include modeling as an explicit part of problem solving because it reminds us to think about modeling errors (that is, errors due to simplifications and assumptions of the model).

Many of the methods in this book are based on discrete distributions, which makes some people worry about numerical errors. But for real-world problems, numerical errors are almost always smaller than modeling errors.

Furthermore, the discrete approach often allows better modeling decisions, and I would rather have an approximate solution to a good model than an exact solution to a bad model.

On the other hand, continuous methods sometimes yield performance advantages—for example by replacing a linear- or quadratic-time computation with a constant-time solution.

So I recommend a general process with these steps:

While you are exploring a problem, start with simple models and implement them in code that is clear, readable, and demonstrably correct. Focus your attention on good modeling decisions, not optimization.

Once you have a simple model working, identify the biggest sources of error. You might need to increase the number of values in a discrete approximation, or increase the number of iterations in a Monte Carlo simulation, or add details to the model.

If the performance of your solution is good enough for your application, you might not have to do any optimization. But if you do, there are two approaches to consider. You can review your code and look for optimizations; for example, if you cache previously computed results you might be able to avoid redundant computation. Or you can look for analytic methods that yield computational shortcuts.

One benefit of this process is that Steps 1 and 2 tend to be fast, so you can explore several alternative models before investing heavily in any of them.

Another benefit is that if you get to Step 3, you will be starting with a reference implementation that is likely to be correct, which you can use for regression testing (that is, checking that the optimized code yields the same results, at least approximately).

Many of the examples in this book use classes and functions defined
in `thinkbayes.py`

. You can download this
module from http://thinkbayes.com/thinkbayes.py.

Most chapters contain references to code you can download from http://thinkbayes.com. Some of those files have dependencies you will also have to download. I suggest you keep all of these files in the same directory so they can import each other without changing the Python search path.

You can download these files one at a time as you need them, or you
can download them all at once from http://thinkbayes.com/thinkbayes_code.zip.
This file also contains the data files used by some of the programs. When
you unzip it, it creates a directory named `thinkbayes_code`

that contains all the code used in
this book.

Or, if you are a Git user, you can get all of the files at once by forking and cloning this repository: https://github.com/AllenDowney/ThinkBayes.

One of the modules I use is `thinkplot.py`

, which provides wrappers for some
of the functions in `pyplot`

. To use it,
you need to install `matplotlib`

. If you
don’t already have it, check your package manager to see if it is
available. Otherwise you can get download instructions from http://matplotlib.org.

Finally, some programs in this book use NumPy and SciPy, which are available from http://numpy.org and http://scipy.org.

Experienced Python programmers will notice that the code in this book does not comply with PEP 8, which is the most common style guide for Python (http://www.python.org/dev/peps/pep-0008/).

Specifically, PEP 8 calls for lowercase function names with
underscores between words, `like_this`

. In this book and the accompanying code,
function and method names begin with a capital letter and use camel case,
`LikeThis`

.

I broke this rule because I developed some of the code while I was a Visiting Scientist at Google, so I followed the Google style guide, which deviates from PEP 8 in a few places. Once I got used to Google style, I found that I liked it. And at this point, it would be too much trouble to change.

Also on the topic of style, I write “Bayes’s theorem” with an
*s* after the apostrophe, which is preferred in some
style guides and deprecated in others. I don’t have a strong preference. I
had to choose one, and this is the one I chose.

And finally one typographical note: throughout the book, I use PMF and CDF for the mathematical concept of a probability mass function or cumulative distribution function, and Pmf and Cdf to refer to the Python objects I use to represent them.

There are several excellent modules for doing Bayesian statistics in
Python, including `pymc`

and OpenBUGS. I
chose not to use them for this book because you need a fair amount of
background knowledge to get started with these modules, and I want to keep
the prerequisites minimal. If you know Python and a little bit about
probability, you are ready to start this book.

Chapter 1 is about probability and Bayes’s theorem;
it has no code. Chapter 2 introduces `Pmf`

, a thinly disguised Python dictionary I use
to represent a probability mass function (PMF). Then Chapter 3 introduces `Suite`

, a kind of Pmf that provides a framework
for doing Bayesian updates. And that’s just about all there is to
it.

Well, almost. In some of the later chapters, I use analytic
distributions including the Gaussian (normal) distribution, the
exponential and Poisson distributions, and the beta distribution. In Chapter 15 I break out the less-common Dirichlet distribution,
but I explain it as I go along. If you are not familiar with these
distributions, you can read about them on Wikipedia. You could also read
the companion to this book, *Think Stats*, or an
introductory statistics book (although I’m afraid most of them take a
mathematical approach that is not particularly helpful for practical
purposes).

The following typographical conventions are used in this book:

*Italic*Indicates new terms, URLs, email addresses, filenames, and file extensions.

`Constant width`

Used for program listings, as well as within paragraphs to refer to program elements such as variable or function names, databases, data types, environment variables, statements, and keywords.

`Constant width bold`

Shows commands or other text that should be typed literally by the user.

`Constant width italic`

Shows text that should be replaced with user-supplied values or by values determined by context.

This icon signifies a tip, suggestion, or general note.

This icon indicates a warning or caution.

Safari Books Online (www.safaribooksonline.com) is an on-demand digital library that delivers expert content in both book and video form from the world’s leading authors in technology and business.

Technology professionals, software developers, web designers, and business and creative professionals use Safari Books Online as their primary resource for research, problem solving, learning, and certification training.

Safari Books Online offers a range of product mixes and pricing programs for organizations, government agencies, and individuals. Subscribers have access to thousands of books, training videos, and prepublication manuscripts in one fully searchable database from publishers like O’Reilly Media, Prentice Hall Professional, Addison-Wesley Professional, Microsoft Press, Sams, Que, Peachpit Press, Focal Press, Cisco Press, John Wiley & Sons, Syngress, Morgan Kaufmann, IBM Redbooks, Packt, Adobe Press, FT Press, Apress, Manning, New Riders, McGraw-Hill, Jones & Bartlett, Course Technology, and dozens more. For more information about Safari Books Online, please visit us online.

Please address comments and questions concerning this book to the publisher:

O’Reilly Media, Inc. |

1005 Gravenstein Highway North |

Sebastopol, CA 95472 |

800-998-9938 (in the United States or Canada) |

707-829-0515 (international or local) |

707-829-0104 (fax) |

We have a web page for this book, where we list errata, examples, and any additional information. You can access this page at http://oreil.ly/think-bayes.

To comment or ask technical questions about this book, send email to bookquestions@oreilly.com.

For more information about our books, courses, conferences, and news, see our website at http://www.oreilly.com.

Find us on Facebook: http://facebook.com/oreilly

Follow us on Twitter: http://twitter.com/oreillymedia

Watch us on YouTube: http://www.youtube.com/oreillymedia

If you have a suggestion or correction, please send email to
*downey@allendowney.com*. If I make a change based on
your feedback, I will add you to the contributor list (unless you ask to
be omitted).

If you include at least part of the sentence the error appears in, that makes it easy for me to search. Page and section numbers are fine, too, but not as easy to work with. Thanks!

First, I have to acknowledge David MacKay’s excellent book,

*Information Theory, Inference, and Learning Algorithms*, which is where I first came to understand Bayesian methods. With his permission, I use several problems from his book as examples.This book also benefited from my interactions with Sanjoy Mahajan, especially in fall 2012, when I audited his class on Bayesian Inference at Olin College.

I wrote parts of this book during project nights with the Boston Python User Group, so I would like to thank them for their company and pizza.

Jonathan Edwards sent in the first typo.

George Purkins found a markup error.

Olivier Yiptong sent several helpful suggestions.

Yuriy Pasichnyk found several errors.

Kristopher Overholt sent a long list of corrections and suggestions.

Robert Marcus found a misplaced

*i*.Max Hailperin suggested a clarification in Chapter 1.

Markus Dobler pointed out that drawing cookies from a bowl with replacement is an unrealistic scenario.

Tom Pollard and Paul A. Giannaros spotted a version problem with some of the numbers in the train example.

Ram Limbu found a typo and suggested a clarification.

In spring 2013, students in my class, Computational Bayesian Statistics, made many helpful corrections and suggestions: Kai Austin, Claire Barnes, Kari Bender, Rachel Boy, Kat Mendoza, Arjun Iyer, Ben Kroop, Nathan Lintz, Kyle McConnaughay, Alec Radford, Brendan Ritter, and Evan Simpson.

Greg Marra and Matt Aasted helped me clarify the discussion of

*The Price is Right*problem.Marcus Ogren pointed out that the original statement of the locomotive problem was ambiguous.

Jasmine Kwityn and Dan Fauxsmith at O’Reilly Media proofread the book and found many opportunities for improvement.

Start Free Trial

No credit card required