Using the recurrence relation $\binom n m = \binom {n - 1} {m - 1} + \binom {n - 1} m$, we develop a dynamic programming algorithm to calculate the binomial coefficient. I am aware that better algorithms exist.

I am excited to announce that gcovr 3.4 has been released!

This release represents over a year of accumulated bug fixes. Support for Windows and for Python 3 has been greatly improved. There are also a number of quality improvements behind the scenes.

Gcovr is a command line tool that uses gcov to produce code coverage reports as text summaries, detailed HTML reports, or Cobertura-compatible XML. I works with the GCC and Clang compilers.

You can pip install gcovr from PyPI, read the overview on GitHub, or read the user guide.

After a lot of refactoring and cleanup, gcovr 4.0 is out!

This release represents four months of work. The focus was on internal changes, but there are lots of enhancements as well: better filters, improved Python 3 support, GCC 8 support, better encoding support via --source-encoding, parallel gcov invocations with -j, and HTML customizations with --html-title, --html-medium-threshold, and --html-high-threshold.

Gcovr is a command line tool that uses gcov to produce code coverage reports as text summaries, detailed HTML reports, or Cobertura-compatible XML. I works with the GCC and Clang compilers.

You can pip install gcovr from PyPI, read the overview on GitHub, or read the user guide.

Gcovr 4.2 is out, and provides a broad array of new features! With the ability to use config files, new output formats like JSON and SonarQube XML, and the ability to combine coverage data from multiple runs, this release should make it easier to create coverage report in more complex scenarios.

Gcovr is a command line tool that uses gcov to produce code coverage reports in various formats, such as text summaries, detailed HTML reports, and various machine-readable formats. It works with the GCC and Clang compilers.

You can pip install gcovr from PyPI, read the overview on GitHub, or read the full documentation.

When designing interfaces / APIs, it is easy to design the interface around the solution space. This makes such interfaces difficult to use, difficult to test, and difficult to maintain. Instead, our interfaces should allow users to easily express their intent.

Cache-aware programming can make a huge performance difference, especially when writing code in C++ or Rust. Python is a much more high-level language, and doesn't give us that level of control over memory layout of our data structures. So does this mean that CPU caching effects aren't relevant in Python?

In this post, we'll conduct some basic experiments to answer this question, by accessing list element either in sequental order or in a random order.

Results indicate that randomized access is consistently slower in Python. Especially as soon as problem sizes outgrow the CPU cache sizes, random access is multiple times slower. Thus, some degree of cache-aware programming may be relevant in interpreted environments like CPython 3.12 as well.

While cleaning up some of my dotfiles, I found what may be the most cursed Python code I have ever written: raw syscalls that required parsing Linux header files.

A few days ago, I was trying to split a data set into various files according to their type, but it was terribly slow. I saved an hour by taking a step back and thinking about my algorithms. Because algorithms matter. But not terribly much.