Magic: The Gathering is a trading card game I happen to like. It also so happens that there is a database of cards available online. Additionally I (like many programmers) kind-of got into Machine Learning recently. Lets see if we can combine these ingredients to come up with something interesting, shall we? Have you ever wondered whether cards got "cheaper" (in terms of Mana) in the past years or how much more a creature costs because it can fly? How much cheaper is a creature that has Defender? I'll be toying around with some card data and do some basic data analysis for practice, education and fun. There shall be some (somewhat hacky) Python code using Pandas, SciKit-Learn and Matplotlib in the end that you can use to reproduce (or extend) what I did (you'll have to wait for the second part for that though).

In this first part we will do some general analysis of the data and see what we can learn about the game with a simple Principal Component Analysis.

Wizards of the Coast, Magic: The Gathering, and their logos are trademarks of Wizards of the Coast LLC in the United States and other countries. © 2009 Wizards. All Rights Reserved. This web site is not affiliated with, endorsed, sponsored, or specifically approved by Wizards of the Coast LLC.

Kakoune offers already various integrations for external tools such as git, ranger and various others. Recently there was also some nice integration of fzf made public (although afaik not (yet) included in the kakoune distribution).

I took all this, put it in my config, modified it to my needs and extended it a little.

These days there are some damn cool things out there to build up your Unixoid (development) environment. This is a medium-sized elaboration on the stuff I like.

Spoilers: Including an editor that can be considered better than VIM in some regards and the single most awesome shell there is (no, not ZSH). I structured it a bit though so you can skip through the parts that are boring to you :-).

I've been watching some PyCon talks online lately and stumbled across a few interesting things, these are mostly notes for myself but feel free to consider them useful ;-)

In the previous article I raised the question on whether -- from a performance standpoint -- one should implement state machines using switch-statements or function pointers.

We saw that switch-statements are compiled to a number of jump/compare instructions that grow at least logarithmically with the number of case-labels. I had to close with the observation that a too contrived example however leads to our compiler actually analyzing our state machine good enough to be able to rewrite our code into unrolled instructions and loops.

In this post I want to discuss a slightly less contrived example that is a (stupid and useless) "parser" for XML data. We will observe that even when the state logic is more complex and transitions depend on unforeseeable input data, the compiler can do smart transformations with switch-statements.