masaers' blog2014-04-16T16:05:02+08:00http://www.masaers.com/feed.post.xmlCopyright 2013-2014 Markus SaersFunctional composition in c++112014-04-12T00:00:00+08:00Markus Saershttp://www.masaers.com<p>The new functional components in c++11 such as <em>lambda closures</em> takes a welcomed step in the direction of making c++ more functional – in the functional paradigm sense of the word, it still remains a dysfunctional language in the sense that there is still an abundance of rope available for hangers. This post will detail my attempt at using some of that rope to make <em>functional composition</em> available to people who are rightfully reluctant to come close to the capricious coil.</p>
<p>Functional composition is when you call a function <em>with the output of another function</em>. Composing function <math xmlns='http://www.w3.org/1998/Math/MathML'><mi>f</mi></math> with function <math xmlns='http://www.w3.org/1998/Math/MathML'><mi>g</mi></math> yields a third function: <math xmlns='http://www.w3.org/1998/Math/MathML'><mi>h</mi><mo>=</mo><mi>f</mi><mo>∘</mo><mi>g</mi></math>, with the definition <math xmlns='http://www.w3.org/1998/Math/MathML'><mi>h</mi><mfenced><mi>·</mi></mfenced><mo>=</mo><mi>g</mi><mfenced><mrow><mi>f</mi><mfenced><mi>·</mi></mfenced></mrow></mfenced></math>. This mechanism can be generalized to any number of functions (because the composition of two functions is also a function).</p>
<p>This is a good example of inductive definitions, which can be solved using <em>variadic templates</em> treated as a list of templates parameters. The list of parameters are treated as a list in a declarative language like <em>prolog</em> or <em>lisp</em>, and is evaluated at compile time. The basic principle is that a list consists of a <em>first element</em> and a <em>shorter list</em> containing all but the first element. As long as the program knows how to handle a single element, the behavior can be recursively defined as the behavior of each element until some <em>base case</em> is reached. The base case is typically the list containing a single element, or the empty list. For functional composition, the base case will be a single function since the composition of no functions is illdefined. The base case is trivially a call to that one function.</p>
<p>The code will be structured so that there is a recursively defined structure called <code>composition</code> which represents the resulting function, and a convenience function called <code>compose</code>, which takes an arbitrary number of functions as input, and returns a <code>composition</code>.</p>
<p>The <code>compose</code> function is trivial as long as you are familiar with variadic templates and perfect forwarding:</p>
<pre><code>#include <tuple>
#include <functional>
#include <type_traits>
template<typename... funcs_T>
inline composition<funcs_T...> compose(funcs_T&&... funcs) {
return composition<funcs_T...>(std::forward<funcs_T>(funcs)...);
}</code></pre>
<p>The function merely deduces the type of the <code>composition</code> from the parameters passed in.</p>
<p>The <code>composition</code> structure is where all the interesting stuff happens. First off, we need to declare the existence of the structure, and allow it to be parameterized with any number of functions:</p>
<pre><code>template<typename...> class composition;</code></pre>
<p>Once the structure is declared, we can define the base case and the inductive case. Let’s start with the easier base case, which merely wraps a single function:</p>
<pre><code>template<typename func_T>
class composition<func_T> {
public:
typedef typename std::decay<func_T>::type func_type;
inline composition(func_T&& func) : func_m(std::forward<func_T>(func)) {}
inline composition(const composition&) = default;
inline composition(composition&&) = default;
inline composition& operator=(composition x) {
swap(*this, x);
return *this;
}
friend inline void swap(composition& a, composition& b) {
using namespace std;
swap(a.func_m, b.func_m);
}
template<typename... args_T>
inline typename std::result_of<func_type(args_T...)>::type
operator()(args_T&&... args) const {
return func_m(std::forward<args_T>(args)...);
}
protected:
func_type func_m;
};</code></pre>
<p>To be a good citizen, the class defines copy and move constructors, assignment operator and <code>swap</code>. Other than that, it merely wraps a function, taking care to keep valid storage of it (using <code>std::decay</code>). As the base case, the class has only one template parameter. By specializing the class when there are more than one parameter, we can define the inductive case. Somewhat counter-intuitive, this requires three named parameters: the first function, the “head of the list”, and the “tail of the list”. This is necessary, as the tail is actually a variadic template, and thus allowed to be empty; if there was no explicit head of the list, the definition would conflict with te base case. Compilers can typically handle the conflict, but there is no need to confuse the poor compilers more than necessary. To complete the induction, we can use inheritance to have <code>compoistion<a, b, c></code> inherit from <code>composition<b, c></code>. Fulfilling only good citizenry, the class looks like this:</p>
<pre><code>template<typename func_T, typename head_T, typename... tail_T>
class composition<func_T, head_T, tail_T...>
: public composition<head_T, tail_T...>
{
typedef composition<head_T, tail_T...> base_type;
public:
typedef typename std::decay<func_T>::type func_type;
inline composition(func_T&& func, head_T&& head, tail_T&&... tail)
: base_type(std::forward<head_T>(head), std::forward<tail_T>(tail)...)
, func_m(std::forward<func_T>(func))
{}
inline composition(const composition&) = default;
inline composition(composition&&) = default;
inline composition& operator=(composition x) {
swap(*this, x);
return *this;
}
friend inline void swap(composition& a, composition& b) {
using namespace std;
swap(a.func_m, b.func_m);
swap(static_cast<base_type&>(a), static_cast<base_type&>(b));
}
protected:
func_type func_m;
};</code></pre>
<p>Now, all that is missing is the application operator, to actually perform the composed call. Theoretically, it needs to apply the base class to whatever the local function returns. Remember: the first function is applied first, although the nested form puts the first function innermost, which is to the rightmost. The implementation is:</p>
<pre><code>template<typename... args_T>
inline typename std::result_of<base_type(typename std::result_of<func_type(args_T...)>::type)>::type
operator()(args_T&&... args) const {
return base_type::operator()(func_m(std::forward<args_T>(args)...));
}</code></pre>
<p>The trickiest part of writing it was figuring out the return type.</p>
<p>In the end, this allows us to write programs such as:</p>
<pre><code>int add(int a, int b) { return a + b; }
int add_one(int a) { return a + 1; }
int main(const int argc, const char** argv) {
using namespace std;
const auto f = compose(add, add_one);
int a = f(10, 20);
assert(a == 31);
return 0;
}</code></pre>
<p>Note that is would be meaningless to compose the function <code>f</code> with anything, as it requires two parameters, while functions in c++ are limited to returning a single value. Next up, I will show how you can use parameter unpacking to compose functions that return <code>tuple</code>s with functions that expect multiple parameters.</p>Using CRTP to easily hijack operators in c++112014-01-22T00:00:00+08:00Markus Saershttp://www.masaers.com<p>In this post I will show a neat trick for hijacking operators in c++ without writing tons of repeating code. As an example, I will hijack the output operator <code><<</code>, which is used to place objects into a stream. This allows for construction such as <code>cout << multi('=', 80)
<< endl;</code> to fill a standard console line with equality signs. The hijacking will allow me to write a very small class that focuses on the core task: to hijack the stream output iterator and put 80 equality signs into it.</p>
<p>To allow the multiplier object to focus on its core task, I will employ the curiously recurring template patten (CRTP) with an empty base-class. Since we are hijacking the output operator, which is left-associative, I will call this base class an <code>ltor_insert</code>. It is, after all, inserted in a left-to-right associative operator chain.</p>
<pre><code>template<typename insert_T> struct ltor_insert {};</code></pre>
<p>It is an empty structure that takes some other class as a template parameter. The template parameter is what causes it to be a CRTP base-class. The curiosity of the pattern shows in the derived class, in this example, the class that will determine what happens when the output stream is hijacked. I call it <code>multi_t</code>, because it is a type that will be returned when the factory function <code>multi</code> is called.</p>
<pre><code>template<typename what_T>
class multi_t : public ltor_insert<multi_t<what_T> > {
};</code></pre>
<p>As you can see, it inherits from <code>ltor_insert</code>, which makes it a derived class, but it derives from an instance of <code>ltor_insert</code> that is parameterized with itself! This is the curious part of the curiously recurring template pattern. It works by making <code>ltor_insert</code> aware of its derived classes, which we will exploit in the hijacking.</p>
<p>It also takes the thing-to-be-printed as a templated type (<code>what_T</code>), allowing you to switch freely between eg. <code>char</code>s and <code>string</code>s. The task of the object is to remember what needs to be printed and how many times, so it will need members to store that information (don’t worry, since it goes out of scope so fast, this will all be optimized away by the compiler), and a constructor to populate them:</p>
<pre><code>template<typename what_T>
class multi_t : public ltor_insert<multi_t<what_T> > {
public:
inline multi_t(what_T&& what, uint32_t times)
: what_m(std::forward<what_T>(what)), times_m(times)
{}
private:
what_T what_m;
uint32_t times_m;
};</code></pre>
<p>Astute readers will notice that this class potentially stores references, which is generally a <em>very</em> bad idea (don’t do that if you can avoid it!). In this case, there are redeeming qualities: the only place where the <code>what_m</code> member is manipulated is in the constructor, and the benefit of not having to copy things passed in as references into the object makes it a reasonable trade-off.</p>
<p>To code the behavior of the object, we will make it into a unary functor by implementing the <code>()</code>-operator. Since we are hijacking an output stream, the functor will take a reference to an <code>std::ostream</code> as its sole parameter and return type. The implementation just puts <code>times_m</code> instances of <code>what_m</code> into the stream passed to the function, and then returns it. The final class looks like this:</p>
<pre><code>template<typename what_T>
class multi_t : public ltor_insert<multi_t<what_T> > {
public:
inline multi_t(what_T&& what, uint32_t times)
: what_m(std::forward<what_T>(what)), times_m(times)
{}
inline std::ostream& operator()(std::ostream& s) const {
for (uint32_t i = 0; i < times_m; ++i) {
s << what_m;
}
return s;
}
private:
what_T what_m;
uint32_t times_m;
};</code></pre>
<p>To construct an instance of <code>multi_t</code>, we have to call:</p>
<pre><code>multi_t<std::string>(std::string("="), 80);</code></pre>
<p>This becomes tedious surprisingly quickly, and doesn’t do much for readability or ease of use. Instead, I like to have a convenience function that derives the correct parameters to <code>multi_t</code> by what was actually passed into it:</p>
<pre><code>template<typename what_T>
inline multi_t<what_T> multi(what_T&& what, uint32_t times) {
return multi_t<what_T>(std::forward<what_T>(what), times);
}</code></pre>
<p>This allows <code>multi</code> to be called with any first parameter, and the convenience function and the corresponding return type will be instantiated when needed. Also note the use of perfect forwarding to guarantee that the meta function does not interfere by causing unwanted copying of the thing being multiplied.</p>
<p>So far, everything looks pretty straight-forward (except for the CRTP stuff, which you say will be useful right about now (if you want me to keep reading; yes, yes, I now, getting to it!)). The remaining part is the “special sauce” that ties the whole dish together. But, lets start in the beginning. What we want is to have an <code><<</code> operator for <code>std::ostream</code> which defines what happens when a <code>multi_t</code> is inserted into the stream. We would typically write something like this:</p>
<pre><code>template<typename what_T>
inline std::ostream&
operator<<(std::ostream& s, const multi_t<what_T>& x) {
return x(s);
}</code></pre>
<p>(Well, actually, we would probably have put the implementation of <code>multi_t::operator()</code> straight into the implementation above). Now, lets see how we can generalize this.</p>
<p>First, we can replace the explicit <code>multi_t</code> with “anything that derives from <code>ltor_insert</code>. This is where the CRTP comes into play, as it allows us to statically cast the <code>ltor_insert</code> into its derived class and reach the functionality implemented there!</p>
<pre><code>template<typename insert_T>
inline std::ostream&
operator<<(std::ostream& s, const ltor_insert<insert_T>& x) {
return static_cast<const insert_T&>(x)(s);
}</code></pre>
<p>Second, we can replace the stream with a template parameter, after all, it makes little sense to only be able to hijack an output stream.</p>
<pre><code>template<typename base_T, typename insert_T>
inline base_T&
operator<<(base_T& base, const ltor_insert<insert_T>& x) {
return static_cast<const insert_T&>(x)(base);
}</code></pre>
<p>Third, we can take the base by universal reference. This works because of the reference collapsing rules in c++11, which we can use to ensure perfect forwarding, that is: the <code>base</code> is passed into the hijacking functor exactly as it was passed into the <code><<</code>-operator:</p>
<pre><code>template<typename base_T, typename insert_T>
inline base_T&&
operator<<(base_T&& base, const ltor_insert<insert_T>& x) {
return static_cast<const insert_T&>(x)(std::forward<base_T>(base));
}</code></pre>
<p>Fourth, we can infer the return type from the inserted functor. That is, instead of insisting that a hijacking functor returns the same type that it is passed, we will allow the operator to result in whatever-the-hijacking-functor-results-in. C++11 provides the <code>auto</code> return type and the <code>decltype</code> keyword for this purpose:</p>
<pre><code>template<typename base_T, typename insert_T>
inline auto
operator<<(base_T&& base, const ltor_insert<insert_T>& x) ->
decltype(static_cast<const insert_T&>(x)(std::forward<base_T>(base))) {
return static_cast<const insert_T&>(x)(std::forward<base_T>(base));
}</code></pre>
<p>The return type is specified to be the keyword <code>auto</code>, which allows you to use the parameters passed in to the function to infer what the actual return type will be. This needs to be after the parameter list, because it depends on it. After the parameter list, add an arrow <code>-></code>, and what the inferred type should be. In this case, we use the expression we want to return, and specify that the return type is whatever-the-expression-is-declared-to-result-in, which is what <code>decltype</code> gives us.</p>
<p>With all the new degrees of freedom, we might want to secure up against the operator being called with a base <code>ltor_insert</code>. One way to do this is to build a reasonable default behaviour into <code>ltor_insert</code>, such as just returning whatever is passed in:</p>
<pre><code>template<typename insert_T> struct ltor_insert {
template<typename base_T>
inline base_T&& operator()(base_T&& base) const { return base; }
};</code></pre>
<p>Finally, we want to be able to handle different ways of passing in the hijacker. We have the constant reference version, but we also need the non-constant reference, and the r-value reference (which replaces call-by-value in c++11):</p>
<pre><code>template<typename base_T, typename insert_T>
inline auto
operator<<(base_T&& base, ltor_insert<insert_T>& x) ->
decltype(static_cast<insert_T&>(x)(std::forward<base_T>(base))) {
return static_cast<insert_T&>(x)(std::forward<base_T>(base));
}
template<typename base_T, typename insert_T>
inline auto
operator<<(base_T&& base, ltor_insert<insert_T>&& x) ->
decltype(static_cast<insert_T&&>(x)(std::forward<base_T>(base))) {
return static_cast<insert_T&&>(x)(std::forward<base_T>(base));
}</code></pre>
<p>And that’s it! To fill a console line with 80 equality signs, we can write:</p>
<pre><code>cout << multi('=', 80) << endl;</code></pre>
<p>Which will expand into:</p>
<pre><code>cout << multi_t<char>('=', 80) << endl;</code></pre>
<p>Which will expand into:</p>
<pre><code>operator<<(cout, multi_t<char>('=', 80)) << endl;</code></pre>
<p>Which will expand into:</p>
<pre><code>static_cast<multi_t<char>&&>(ltor_insert<multi_t<char>&&>(x)(cout)) << endl;</code></pre>
<p>(where <code>x</code> is a <code>multi_t</code> keeping track of “80 equality signs”.) Which is really just calling:</p>
<pre><code>x.operator()(cout) << endl;</code></pre>
<p>Which puts 80 equality signs into <code>cout</code> and returns <code>cout</code>, which means that the expression reduces to:</p>
<pre><code>cout << endl;</code></pre>
<p>After 80 equality signs have been put into <code>cout</code>. Like a boss.</p>Snaps decorum2013-12-22T00:00:00+08:00Markus Saershttp://www.masaers.com<p>It is no secret that we Scandinavians are fond of our flavored “vodka”: <em>snaps</em>, <em>akvavit</em> (from ‘aqua vitae’, water of life), <em>brännvin</em> (‘burn-wine’, distilling is typically referred to as burning), or whatever you call it. With my Swedish background, I use the term <em>snaps</em> to speak of the herbal liquor that litteraly goes with <em>all</em> festive meals.</p>
<p>As snaps holds such an important position in Scandinavian festivitis, it should come as no surprise that there are plenty of etiquette surronding it as well. And with anything involving plenty of etiquette, it should come as no surprise that there are plenty of misconseptions about how things should be done. This post will get to the bottom of what is right and why by offering the truth™.</p>
<p>A side note on etiquette: always remember that the main point of etiquette is to facilitate social interaction. The instant it stops doing so all bets are off the table. This means that if you find yourself in a situation where people are barbarically butchering any notion of <em>true etiquette</em>™, “do as the Romans”.</p>
<h2 id="the_basics">The basics</h2>
<p>Snaps is typically served ice cold (because of the alcoholic content, it is possible to get it below zero degrees Celsius, which gives it a pleasant viscosity) in small slender glasses (typically holding 3–6 cl). Drinking snaps is a communal activity, and as such, some measure of coordination is needed lest someone gets left behind. Although a toast among friends might be sufficient, Swedes tend to prefer a song. Whether the actual drinking happens at a specific place in the song, or at the end, it is always prudent to raise you glass towards the people sitting around you to acknowledge that you are about to share this ancient tradition. It is equally prudent to again raise your glass once you have tasted the water of life, as to say: I too survived!</p>
<p>A common misunderstanding is that you have to empty the glass every time. This is likely due to the confusing naming of the snapses, as the first one is referred to as <em>Helan</em> (‘the Whole’). This is not a description of how much you drink, but how much is left in the glass before you drink. The snaps after Helan is called <em>Halvan</em> (‘the Half’), which reflects the fact that you would typically get one glass, which you were supposed to drink in two goes. What was half a glass back then (one <em>jungfru</em>, approximately 8.5 cl) is pretty close to what a full glass is today (arond 3–6 cl), so the amount of snaps that “the Whole” corresponds to works out to be about one glass, but that is not the reason for the name.</p>
<p>To make a snaps last longer, and to be able to socialize throughout multiple <em>snapsvisor</em> (‘snaps songs’, singular: <em>snapsvisa</em>) without getting shit faced, it is common to “bite the snaps off” three times, meaning that you dring about a third for each song.</p>
<h2 id="the_order_of_snaps">The order of snaps</h2>
<p>The communal nature of deinking snaps also means that it falls on everyone to keep track of how manny has been had already. Much like the aboriginals of Australia sing the features of the land into communal memory and thus existence, Swedes sing to communaly remember the snaps count. We do this by naming the different drinks depending on where in the order they occur. The names are:</p>
<ol>
<li>Helan (‘the Whole’)</li>
<li>Halvan (‘the Half’)</li>
<li>Ternsen (‘the Third’)</li>
<li>Kvarten (‘the Fourth’, sometimes spelt Quarten)</li>
<li>Kvinten (‘the Fifth’, sometimes spelt Quinten)</li>
<li>Sexten (‘the Sixth’)</li>
<li>Septen (‘the Seventh’)</li>
</ol>
<p>At this point people start to diagree, which may not come as a surprise, seeing as people are about to have their eighth serving… but most peole would agree that the following fit somewhere down the line, and in the given order:</p>
<ul>
<li>Smuttan (‘The Smutt’, might refer to <em>smutta</em>, which means to just drink a very small amount)</li>
<li>Smuttans unge (‘The child Smuttan’)</li>
<li>Lilla Manasse (‘Little Manasse’)</li>
<li>Kreaturens uppståndelse (‘The resurrection of the creatures’)</li>
</ul>
<p>Any respectable book of snapsvisor will have a list of the names assumed in that particular collection.</p>
<h2 id="the_singing">The singing</h2>
<p>The songs are generally traditional tunes with lyrics glorifying drinking. It is also common to allude to the current festivity, or to which drink in the order is about to be had. The one that all Swedes know by heart is called <em>Hellan går</em> (‘The Whole goes’):</p>
<blockquote>
<p>Helan går, sjung hoppfaderallanallanlej<br /> Helan går, sjung hoppfaderallanlej<br /> Och den som inte Helan tar<br /> Hen heller inte Halvan får<br /> Helan går<br /> … sjung hopp faderallan lej!<br /></p>
</blockquote>
<p>The drink is ingested between the ellipses. An English translation goes something like this:</p>
<blockquote>
<p>The Whole goes, sing hop-pha-der-allan-allan-ley<br /> The Whole goes, sing hop-pha-der-allan-ley<br /> And the ones who doesn’t take the Whole<br /> (S)He neither gets to take the Half<br /> The Whole goes<br /> … sing hop pha-der-allan ley!<br /></p>
</blockquote>
<p>A more singable version could be:</p>
<blockquote>
<p>The Whole goes down, sing hop-pha-der-allan-allan-ley<br /> The Whole goes down, sing hop-pha-der-allan-ley<br /> Now, if you were to miss the Whole<br /> You will not get to take the Half<br /> The Whole goes down<br /> … sing hop pha-der-allan ley!<br /></p>
</blockquote>
<p>A popular and well-known example of a song with a festive theme is <em>Hej tomtegubbar</em> (<em>tomtegubbar</em> is a tricky word to translate, as <em>tomte</em> is a combined gnome and Santa Clause, and <em>gubbar</em> means ‘old men’… I’ll go with ‘Hello Santamen’):</p>
<blockquote>
<p>Hej tomtegubbar slå i glasen och låt oss lustiga vara<br /> Hej tomtegubbar slå i glasen och låt oss lustiga vara<br /> En liten tid, vi leva här med mycket möda och stort besvär<br /> Hej tomtegubbar slå i glasen och låt oss lustiga vara!<br /></p>
</blockquote>
<p>Which translates into:</p>
<blockquote>
<p>Hello Santamen, pour into the glasses and let us be funny<br /> Hello Santamen, pour into the glasses and let us be funny<br /> A short time, we live here with many toils and great discomfort<br /> Hello Santamen, pour into the glasses and let us be funny<br /></p>
</blockquote>
<p>This has a very typical alcohol romantic message in a Christmassy setting. The idea is that the toild and tears of every-day life can be drunk away as long as you keep pouring into the glasses. I personally view it as a very black kind of humor, which I am very fond of.</p>
<h2 id="the_end">The end</h2>
<p>So, now you know a little more about Scandinavian culture, and if you get the chance, try to enjoy the snaps and the singing. Most people will sing more willingly than well, so if you don’t speak the language, just try to hum a long and follow suit when people start drinking.</p>
<p>My favorite flavors (in alphabetical order) are: Bäska Droppar (‘bitter drops’), Skåne Akvavit (‘Scania akvavit’) and Ösgöta Sädes Brännvin (‘east Gothia grain burn-wine’). Scania is the southern-most province of Sweden (the truck brand is named after the province). East Gothia is also a province of Sweden.</p>Implementing the Poisson distribution in c++2013-10-08T00:00:00+08:00Markus Saershttp://www.masaers.com<p>In statistics, you frequently need to find the probability of a particular outcome given some distribution. The problem is that this functionality is surprisingly hard to come by in c/c++.</p>
<p>Of course, it is possible to rely on <a href="http://www.boost.org/">Boost</a>, which contains everything you might need, but also represents a very heavy dependency. <a href="http://www.boost.org/">Boost</a> comes with probability mass/density functions for all the common distributions. C++11 also comes standard with a host of distributions, but they have no functions for evaluating the probability of an outcome, only functions to generate random outcomes from the distributions. This makes sense because they are located in the <a href="http://www.cplusplus.com/reference/random/"><code>random</code></a> header, but also doesn’t make sense, since there are many more things you might want to do with a distribution.</p>
<p>So, without relying on <a href="http://www.boost.org/">Boost</a>, it would be pretty straight forward to just take the formula for the probability mass function (pmf) and implement in, right? Well, let’s take a closer look at the pmf of the Poisson distribution:</p>
<math display='block' xmlns='http://www.w3.org/1998/Math/MathML'>
<mi>f</mi><mfenced separators=';'><mi>k</mi><mi>λ</mi></mfenced>
<mo>=</mo>
<mfrac>
<msup><mi>λ</mi><mi>k</mi></msup>
<mrow><mi>k</mi><mo>!</mo></mrow>
</mfrac>
<msup>
<mi>e</mi>
<mrow><mo>−</mo><mi>λ</mi></mrow>
</msup>
</math>
<p>We immediately notice that the factorial (<math xmlns='http://www.w3.org/1998/Math/MathML'><mi>k</mi><mo>!</mo></math>) is potentially tricky to calculate precisely, but that doesn’t really matter, as we will compress the result down to a single <code>double</code> to represent the probability anyway. We can just use the built-in gamma function (<code>tgamma</code> from the <code>cmath</code> header) to approximate the result since <math xmlns='http://www.w3.org/1998/Math/MathML'>
<mrow><mi>k</mi><mo>!</mo></mrow>
<mo>=</mo>
<mrow><mo>Γ</mo><mfenced><mrow><mi>k</mi><mo>+</mo><mn>1</mn></mrow></mfenced></mrow>
</math> This does, however, not quite solve our problem, because the factorial function has the inherent problem of resulting in <em>very</em> large numbers, which means that a <code>double</code> overflows when calculating the factorial of values around 170. This is an inherent limitation of the factorial/gamma function and <code>double</code>s, and there is nothing we can do about it.</p>
<p>Instead, we have to return to the pmf we are trying to solve. We notice that we are not actually concerned with the result of the factorial function as such, but rather the <em>ratio</em> between the exponentially growing <math xmlns='http://www.w3.org/1998/Math/MathML'><msup><mi>λ</mi><mi>k</mi></msup></math> and the factorial function. When solving problems involving <em>very</em> large numbers, it is frequently useful to convert them into logarithmic domain (if you can stand the loss in precision, which we can, since we will compress the result into a single probability represented as a <code>double</code>). The logarithm of the factorial function becomes a sum, which we will have no problems representing with a double, and which we can easily calculate with a call to the purpose-built function <code>lgamma</code>, which also comes standard in the <code>cmath</code> header.</p>
<p>By using the gamma function instead of the factorial, and solving the pmf in logarithmic domain, we get the following function:</p>
<math display='block' xmlns='http://www.w3.org/1998/Math/MathML'>
<mrow><mi>f</mi><mfenced separators=';'><mi>k</mi><mi>λ</mi></mfenced></mrow>
<mo>=</mo>
<mrow>
<mfrac>
<msup><mi>λ</mi><mi>k</mi></msup>
<mrow><mi>k</mi><mo>!</mo></mrow>
</mfrac>
<msup><mi>e</mi><mrow><mo>−</mo><mi>λ</mi></mrow></msup>
</mrow>
<mo>=</mo>
<mrow>
<mfrac>
<msup><mi>λ</mi><mi>k</mi></msup>
<mrow><mo>Γ</mo><mfenced><mrow><mi>k</mi><mo>+</mo><mn>1</mn></mrow></mfenced></mrow>
</mfrac>
<msup><mi>e</mi><mrow><mo>−</mo><mi>λ</mi></mrow></msup>
</mrow>
<mo>=</mo>
<msup>
<mi>e</mi>
<mrow>
<mi>ln</mi>
<mfenced>
<mrow>
<mfrac>
<msup><mi>λ</mi><mi>k</mi></msup>
<mrow><mo>Γ</mo><mfenced><mrow><mi>k</mi><mo>+</mo><mn>1</mn></mrow></mfenced></mrow>
</mfrac>
<msup><mi>e</mi><mrow><mo>−</mo><mi>λ</mi></mrow></msup>
</mrow>
</mfenced>
</mrow>
</msup>
<mo>=</mo>
<msup>
<mi>e</mi>
<mrow>
<mrow><mi>k</mi><mi>ln</mi><mi>λ</mi></mrow>
<mo>−</mo>
<mrow><mi>ln</mi><mo>Γ</mo><mfenced><mrow><mi>k</mi><mo>+</mo><mn>1</mn></mrow></mfenced></mrow>
<mi>λ</mi>
</mrow>
</msup>
</math>
<p>Which avoids the overflow problems, because only the logarithms of the large numbers are being manipulated. It is also straight forward to implement. It even keeps within the confines of c, no c++ stuff needed! Here is a bare-bone version of the code:</p>
<pre><code> #include <cmath>
double poisson_pmf(const double k, const double lambda) {
return exp(k * log(lambda) - lgamma(k + 1.0) - lambda);
}</code></pre>
<p>The only difference between the c++ version above, and the c version of the code is that the c version includes <code>math.h</code> instead of <code>cmath</code>.</p>
<p>As an added benefit of using the gamma function rather than the factorial function, we have also generalized the pmf to reals, rather than merely be valid for integers. A similar approach is also useful for other probability mass/density functions.</p>