Bryan St. Amour's Blog

Coffee Drinkers Have Lower Risk of Death

2012-05-17T00:00:00-04:00

I found this article over at Slashdot: it seems a NIH study has found that coffee drinkers have a lower risk of death! Sweet! With the amount of coffee I injest in a day, I’m probably immortal by now!

The full article can be read here, (NIH) but the actual published paper is behind a paywall (the New England Journal of Medicine.)

From the NIH:

Coffee drinkers were less likely to die from heart disease, respiratory disease, stroke, injuries and accidents, diabetes, and infections, although the association was not seen for cancer. These results from a large study of older adults were observed after adjustment for the effects of other risk factors on mortality, such as smoking and alcohol consumption. Researchers caution, however, that they can’t be sure whether these associations mean that drinking coffee actually makes people live longer. The results of the study were published in the May 17, 2012 edition of the New England Journal of Medicine.

So it seems like I’m good up to cancer. And also:

The researchers found that the association between coffee and reduction in risk of death increased with the amount of coffee consumed.

Jackpot! Long live the brew.

Timing Functions with Chrono

2012-05-13T00:00:00-04:00

I use IBM’s Cplex Linear Optimizer a lot for the work I do, and though it has great built-in facilities to track how much time is spent solving a linear (or integer) program, sometimes I need to compare the runtimes of Cplex vs. some hand-rolled heuristics written in plain C++. In these cases I’m glad that C++11 brought the chrono library over from boost. Chrono gives me access to lots of great tools for tracking durations, and in this blog post I will share with you some code I wrote to track the length of time an arbitrary function takes to run using chrono!

Chrono has three clocks available for use in your code:

// the wall clock from your system.
std::chrono::system_clock

// a monotonic clock.
std::chrono::steady_clock

// the clock with the shortest tick period on the system.
std::chrono::high_resolution_clock

There are plenty of features for the clocks, but for the sake of timing functions we really need only two things: a point in time, and a duration. To access the current time point from a clock, we call the static member function now(). For example, if we wanted to get the current time from the system clock, we would use the following code:

// The resulting type is something like
// std::chrono::system_clock::time_point,
// which is itself a type alias to
// std::chrono::time_point<
//   std::chrono::system_clock
// >, so you see why we use 'auto' here.
auto current_time = std::chrono::system_clock::now();

Time points have the binary minus operator overload defined, and the result of the operation is a duration of time. So if you want to track how long a block of code takes to run, you can do the following:

auto start_time = std::chrono::system_clock::now();

//
// ... code here.
//

// Actual type:
// std::chrono::duration<
//   std::chrono::system_clock::rep
// >
auto time_taken =
  start_time - std::chrono::system_clock::now();

God bless the auto keyword :-)

And now combining that together with tuples, we create a generic function to measure the run time of other functions using the clock of the user’s choice:

template <typename Clock, typename Func>
inline auto time_function(Func&& f)
  -> typename std::enable_if<
       !is_void<decltype(f())>::value,
       std::tuple<
         decltype(f()),
         typename Clock::duration
       >
     >::type
{
    auto start_time = Clock::now();
    auto result = f();
    auto time_taken = start_time - Clock::now();
    return std::make_tuple(result, time_taken);
}

The reason for using enable_if is that when we’re given a function that returns void, we don’t worry about wrapping up the result in a tuple because there’s no result to wrap! We’ll write another definition of time_function to work with void functions, and the enable_if will guarantee that when it comes time to pick which version of the function to call, only one definition will be legal (recall that C++ functions cal only be overloaded based on the types and number of parameters, NOT the return type - without enable_if my code would violate the one definition rule.) The void version is as follows:

template <typename Clock, typename Func>
inline auto time_function(Func&& f)
  -> typename std::enable_if<
       is_void<decltype(f())>::value,
       typename Clock::duration
     >::type
{
    auto start_time = Clock::now();
    f();
    auto time_taken = start_time - Clock::now();
    return time_taken;
}

And now we can use the code like the following to track how long IBM’s Cplex takes to solve a problem.

IloCplex instance;

// ... more code here

using clock_type = std::high_resolution_clock;
auto time_taken_1 =
  time_function<clock_type>([&] { instance.solve(); });

And for instance if I have some code to solve the same problem using native C++, I can access both the result and the time taken:

double result;
clock_type::duration time_taken_2;
// std::tie makes a tuple of references.
// Assume compute_result is a function defined elsewhere to
// return a double.
std::tie(result, time_taken_2) =
  time_function<clock_type>(compute_result);

As you can see, std::chrono makes timing code exection easy as 1 2 3. I use it at work a lot where I need to measure the times taken to solve large problems, and it’s useful to have such a powerful library built right in to the C++ SL, so I don’t have to reach for boost. Using the same timing functions for both Cplex and my own code also rules out the possibility that they are implemented differently - while Cplex may use the system time, I may want to use something else. Chrono removes that kind of doubt and lets me use the same clock for all timing tasks :-)

Billiards

2012-05-13T00:00:00-04:00

I’ve come to the conclusion that I need to play more pool. I’ve always enjoyed it and there’s no reason for my game to be this rusty: tonight my angle shots were all over the map. I just read up on a technique that may help out my game involving envisioning a phantom ball in front of the one I want to hit and aiming directly for it. Hey, at this point anything can help my game.

So, sort of like my “one with the frisbee” experiment I tried a few years ago (a topic for another blog post) I think it’s time for me to get good at pool.

Apache Domain Redirects

2012-05-12T00:00:00-04:00

I tried the whole .ca thing for a bit, but I missed my old bryanstamour.com domain. That thing was with me for years and years, and it just felt weird not using it for my blog. So I got it back! However recently I’ve been doing some C++ blogging and have been getting some small Reddit traffic, so I didn’t want those links to suddenly turn dead. What I set up was an apache redirect that takes any visitor to bstamour.ca and magically whisks them to bryanstamour.com instead.

Since I host several domains on my server, I placed the following snippet inside the virtual host block for the bstamour.ca domain:

Redirect permanent / http://bryanstamour.com/

That trailing slash at the end of bryanstamour.com is very important! Without it, visiting bstamour.ca/about/ would take you to the non-existant domain bryanstamour.comabout

Express your ownership

2012-05-11T00:00:00-04:00

With the new C++11 standard out in the wild, I really hope that programming shops will start using the new features sooner rather than later. Some of these features were added for efficiency, such as move semantics, but other features allow you to better express your intent. One such addition to C++ are the new smart pointers: they allow you to directly express who owns your objects (who gets to clean your objects up.)

Smart pointers: use them

C++11 introduces two new smart pointers for you to utilize: shared_ptr<T> and unique_ptr<T>. There also exists weak_ptr in the standard now, but it doesn’t really convey any meaning, it just exists to break dependency cycles, and so I won’t be talking about it today. As you probably already know, shared_ptr<T> is a reference-counted pointer to an object of type T, and unique_ptr<T> is a pointer to type T that is move-only, in other words there can be only one owner of the pointer.

Aside from the benefit of not having to manually delete your pointers, another reason why you should use these constructs is that they tell you, the programmer, tons more about the pointer. When you see a shared_ptr you know that at any given time there can be many different objects that have access to the underlying data, but it’s okay. When you see a unique_ptr lying around you know that if you have access to it you own it, as nobody else can see it unless you give it away. When you see a raw pointer, you know nothing about it at all, except that it’s a pointer. Are you responsible for deleting this raw pointer? Or does it belong to some other object?

Here’s an example of what I mean by owning a pointer:

struct tree_node
{
    unique_ptr<tree_node> left_child;
    unique_ptr<tree_node> right_child;
    int payload;
};

Every tree_node has two children. It owns those children, and thus it is responsible for cleaning them up when the rapture comes. If I were to show this code to another C++ developer, he or she would immediately know that a tree_node owns its kids and will make sure they’re deleted. Contrast this with a tree_node that uses raw pointers instead: do I really own the child nodes? Probably, but I can’t be certain. With unique_ptr that ownership is a guarantee, not just a hunch. Similarily if I need to share something between several possible owners, using shared_ptr expresses this, instead of having the programmer guess if that raw pointer is a one-off or if it is shared all over the place.

Now what if I don’t own the pointer at all, but still need it? For example, what if we added a pointer to the parent inside each tree_node for quick traversal? I don’t want a shared_ptr because I’m not sharing my parent, and I don’t want to be responsible to clean it up. I don’t want a unique_ptr either because I don’t own my parent. So? Raw pointer!

struct tree_node
{
    // ... same as above.
    tree_node* parent;
};

It expresses that yes I need to keep a pointer to something, yet I’m not in any way responsible for cleaning that pointer up - I’m looking at it, but I don’t own it. If you restrict your use of raw pointers for these instances, then between shared_ptr, unique_ptr, and raw pointers, the next programmer who has to look at your code will know immediately the ownership semantics of your objects.

To summarize:

If you actually own the object, and you are the only owner, use unique_ptr.
If you plan to share the object, ~~or the object has to outlive the current scope (e.g. you want to return it from a function)~~ use shared_ptr.
If you are just looking at the object, use a raw pointer.

New Blog

2012-05-10T00:00:00-04:00

I decided to start a new blog, this time using Jekyll instead of Wordpress. Jekyll isn’t really a blog engine per se, it’s just a simple ruby script that generates static pages from markdown files. I kind of like how simple it is, plus I can now edit my blog posts in emacs, the best editor in the universe, because they’re all plain text. No more having to run mysql on my server either.

So what can you expect from this blog in the future? Well honestly about the same kinds of content as before: a mixture of personal ramblings and technical posts for my fellow programmer geeks. Nothing’s changed, really :-) Oh, but you won’t be able to comment on posts until I get disqus set up.

EDIT: Disqus is now working, comment away!

(Almost) functional programming tips for C++

2012-04-28T00:00:00-04:00

There’s been a bit of interest on reddit recently about functional programming in C++, and since I haven’t blogged in a while, I thought I’d toss in my two cents. This post isn’t a detailed novel of functional programming style in C++: it won’t tell you how to implement graph reduction nor will it proclaim that every function should be a pure constexpr function. What this post will be is a small set of tips that will let you write safer more expressive code today (or tomorrow.)

Use const everywhere

All of your variables should be declared const unless you really need to modify them. Modern C++ compilers can perform some really aggressive optimizations to variables that they know will not be modified. I won’t go into the argument of physical const vs. logical const here, that’s a subject for another blog post.

Prefer to use small functions that do one thing well

This is a pretty obvious point, but I’ll go over it anyways. In programming in any language, you should always say what you mean and mean what you say. If your function is called euclidian_distance, it had better compute the euclidian distance of a range and nothing more! If it did something more than that then it shouldn’t be called euclidian_distance. Do one thing and one thing only in your functions, and give them good names, there should be no surprise “whoops, the distance function wrote some crap to a file” scenarios.

Avoid global variables like the plague (unless you really need them)

This sort of goes hand-in-hand with the point above. Your functions will be so much easier to reason about if they only rely on the parameters passed in, not global variables. Why? Because you can verify that your function is correct by only making assumptions on the input parameters, instead of assumptions on the whole world.

Prefer STL algorithms over hand-rolled loops

Sometimes a for or a while loop is just what the doctor ordered, but in most cases you should prefer to use std::for_each, std::transform, or std::accumulate to perform your looping operation. Why? These higher-order functions have well-defined meanings, and they convey much more information about what your code is doing than a hand-rolled loop. When you see a for loop in somebody’s code, you need to pay attention to the stopping-condition, the upkeep, and the initialization to ensure that you fully understand what is going on. Also the loop body: are there any breaks or continues? With for_each, you know that whatever operation is supplied it is guaranteed to touch every element in the range once and only once, and you know in which order! No hunting for breaks or continues is required, you can understand how the loop behaves just by knowing for_each. Similar arguments hold for transform, and accumulate: they’re well-defined actions. Now if your loop doesn’t fall into something that can be represented by for_each, transform, or accumulate, then by all means use the loop that does the job! But prefer using them over your own loops when you can.

Conclusion

Some may argue that nothing that I brought forth is “functional” programming, but some of the benefits of functional programming, I think, are at least being shown. In functional programming everything is represented by mathematical functions and their compositions. Not every function in C++ can be a one-line return statement, but we can at least take some of the benefits of representing everything as small well-defined functions. Furthermore if we utilize some of the higher-order functions in the STL such as for_each, transform, and accumulate; and use const where we can to avoid accidental mutations, we can go a long way toward writing safer, more understandable code. One of these days I’ll have to put together a more detailed blog post about real functional programming in C++, but this should at least help some people begin to think a little bit more functionally in their day jobs without rewriting their code bases in ML.

Building GCC 4.6.1 on Mac OS X Lion

2011-07-25T00:00:00-04:00

Update: It seems more recent versions of gcc will build without issue using the default compilers that ship with XCode. Building a snapshot of gcc 4.7 works without setting any environment variables.

I installed OS X 10.7 Lion a few days ago on my laptop and tried to compile GCC 4.6.1 from source, and I kept running into errors with the compiler that ships with XCode. It turns out that gcc, g++, etc are all symbolic links to the llvm compilers, but gcc-4.2 is still there in /usr/bin, so I wasn’t completely left high and dry. Here are the steps I followed to build GCC 4.6.1:

Get and install the prerequisite libraries: GCC 4.6.1 relies on three libraries (and a few more if you want to enable certain kinds of code optimizations). They are: GMP, MPFR, and MPC.
Get the GCC source and untar it on your system.

Before running the configure script, set your environment variables to use gcc-4.2, not clang:

 $ export CC=/usr/bin/gcc-4.2
 $ export CXX=/usr/bin/g++-4.2
 $ export CPP=/usr/bin/cpp-4.2
 $ export LD=/usr/bin/ld

Configure, make, and make install just like normal.

Make sure you read the documentation for building GCC for when it comes to configuring your build - there are a ton of options!

If all goes well, you should have a working version of GCC 4.6.1 on your system. Now it’s time to compile some C++11 code! (I hear they support constexpr now ;))