ProbabilityToFriendlyString with qualitiative descriptions (and in 8 languages!)

TL;DRProbabilityToFriendlyString now also returns a qualitative description of a probability (“Still possible”, “Flip a coin”, “Good chance”, etc.). See a demo here, and credit to the New York Times for coming up with these!

After the initial release of ProbabilityToFriendlyString, I periodically ported it to more languages, and it’s now done in 8. (JavaScript, Python, C#, Java, Ruby, PHP, Rust, and LabVIEW NXG) I did this as a way of refreshing my knowledge about these languages – Rust was the only one I had never used before, although it had been a long time for some of them! It was also neat to learn how to publish packages to various repositories. I originally was trying to do things in a very idiomatic way in each language, but I’m not sure I really succeeded at that. It also makes a very nice GitHub language bar:

Anyway, when I was obsessively watching the New York Times’ Iowa caucus projects (…yeah) together with the probability there was a qualitative description (the “Eventual winner?” column), and it seemed like a nice addition to the library. The downside is that it’s kind of a pain to update logic and tests for 8 different languages!

I originally was just watching the page and recording a bunch of data so I could derive the rules for what string gets used when. After doing that for a while (and getting frustrated because the whole Iowa mess was making the page not update frequently!) I did some spelunking and found the source, which made it very clear what the rules were. Fun stuff!

I also did this the proper Git way with branches and stuff, and discovered that Fork is a pretty nice GUI client! Previously I used the command-line and GitHub Desktop for my basic needs. At work I use Visual Studio for branching and stuff, and Fork is even more powerful but still pretty easy to use. Kudos!

baseball win expectancy finder now has balls and strikes!

Here it is!

This wasn’t too much work, and like I mentioned last time it was nice to work on adding a new feature to something. Although I guess I did recreate the app’s shell with create-react-app, I didn’t port it to TypeScript 🙂

One annoying part is that there’s just not that much data so you can pretty easily get into situations where the stats are probably “wrong”. For example, in the top of the 8th inning, no outs or runners, home team up by 2, and a 2-0 count the home team has an 87.08% chance to win. But if the batter gets another ball to make the count 3-0 (good for the visiting team), now the home team has an 88.11% chance to win. I guess I should add a warning when the sample size gets too small or something. (although I don’t know what “too small” is)

I was a little worried that adding balls and strikes would bloat the size of the data files, which did happen. The worst-case is that it would increase the file size by 12x (4 choices for balls * 3 for strikes), but in practice it’s more like 9x. But it turns out that computers are fast so doing the lookups is only barely slower than before.

My original plan was to add the balls and strikes data to the mobile app (and make it an in-app purchase to unlock), but the increase in data size and corresponding memory usage make me less excited about it. Maybe at some point…

Marriage map now in React + TypeScript!

I ported my same-sex marriage map in React + TypeScript! It now uses the usStateMap component I wrote a while ago.

This was interesting because the original map was just vanilla JavaScript and jQuery, so the “port” was really more of a rewrite. It also meant I got to get rid of a ton of logic around state management and also some pretty hacky code around drawing the map itself.

I went ahead and published the code on GitHub (it was public before but in a less convenient way), too, mostly so the usStateMap component now shows that two projects use it 🙂

I ended up leaving out a few features because they didn’t make a ton of sense (flashing map colors, pending court cases), and I also decided to make the cartogram view the default because it’s a more accurate representation of the number of people that were under particular laws at a particular time.

Honestly, porting all of these projects to React + TypeScript is starting to feel tedious, so I’m going to take a break and start working on some new features for some stuff. Should be fun!

(and it still gives me a bit of a thrill to load the page and see an all-blue map!)

How common are walk-off walks (on four pitches!) in baseball?

I’ve been following the Astros pretty closely this season (since they’re very good this year!), and so when I saw they had won a game on a walk-off walk, I was curious how common that was.

A walk-off is when the home team wins the game on that play, by scoring a run to go ahead in the ninth or later inning. So a walk-off walk is when that happens because the batter is walked. It’s kind of very dramatic and anticlimactic at the same time!

In this case, the walk was on four pitches, which seemed exceptionally rare, because you might as well throw at least one strike, right? At first I thought “maybe this has never happened before!”, but (spoiler!) it turns out there are a lot of baseball games that have been played. So I wanted to at least know how common it was.

My baseball win expectancy finder is powered by a Python script that can parse games, so I extended the parsing code to make it easier to run these sorts of reports and ran it. (source available on GitHub, see WalkOffWalkReport in

So, the numbers: in the ~128000 games I have data for, a walk-off walk has happened only 442 times. That sounds like a lot but it’s only around 7 times a season. Not all the games have pitch-by-pitch data, but ~73500 of them do, and walk-off walks on four pitches have happened only 60 times. (not including data from this year)

Since there are roughly 2100 games per season (including the playoffs), this means we’d expect this to happen around 1 time per season. Which is indeed pretty rare!

In fact, Altuve got his walk-off walk with 2 outs – walk-off walks with 2 outs have only happened 257 times (~4 times/season), and ones on four pitches have only happened 41 times, which is around 2 every 3 seasons!

When I was in the middle of this work I remembered that baseball-reference has an incredibly powerful Event Finder, and lo and behold it can do this search as well. In fact, at first our numbers were pretty far off so I found some bugs in my script 🙂 (the numbers are still off by a few because it’s counting a walk where the fourth ball was a wild pitch and a runner scored, while my script doesn’t count those)

My original thought was that I could make it easier to use my script to find stuff like this, but the baseball-reference Event Finder is so incredibly powerful and relatively easy to use I probably won’t bother. Kudos to them!

clue solver – now in TypeScript!

Here’s a new version of my Clue solver! It works exactly the same as the old version, but now it uses a more standard React build system (so maybe it’s a little faster?) and I ported it to TypeScript.

TypeScript is now my favorite way to write React apps. It’s really nice to have a real type system with compile-time errors, and it gives me much more confidence when I refactor things.

For a comparison, here’s the old code in plain JavaScript, and here’s the new code in TypeScript. One representative sample of how much nicer things are, in the History class’s render method:

Old code:

for (var i = 0; i < this.props.history.length; ++i)
    var event = this.props.history[i][0];
    var eventType = event[0];
    var description = '';
    if (eventType === "suggestion") {
        description = this.props.playerInfo[event[1]][0] + " suggested " + CARD_NAMES[0][event[2]].external + ", " + CARD_NAMES[1][event[3]].external + ", " + CARD_NAMES[2][event[4]].external + " ";
        if (event[5] == -1) {
            description += " - no one refuted";
        else {
            description += " - refuted by " + this.props.playerInfo[event[5]][0] + " with card ";
            if (event[6][0] == -1 && event[6][1] == -1) {
                description += "Unknown";
            else {
                description += CARD_NAMES[event[6][0]][event[6][1]].external;
    } else if (eventType === "whoOwns") {
        var player = "Solution (case file)";
        if (event[1] < this.props.playerInfo.length) {
            player = this.props.playerInfo[event[1]][0];
        description = CARD_NAMES[event[2][0]][event[2][1]].external + " owned by " + player;
    entries.push(<li key={i}>{description}</li>);

New code:

let entries = [];
for (let i = 0; i < this.props.history.length; ++i)
    let event = this.props.history[i].event;
    let description = '';
    switch (event.history_type) {
        case "suggestion":
            description = this.props.playerInfos[event.suggester_index].name + " suggested " +
                cardNameFromCardIndex({ card_type: CardType.Suspects, index: event.suspect_index }).external + ", " +
                cardNameFromCardIndex({ card_type: CardType.Weapons, index: event.weapon_index }).external + ", " +
                cardNameFromCardIndex({ card_type: CardType.Rooms, index: event.room_index }).external + " ";
            if (event.refuter_index == -1) {
                description += " - no one refuted";
            else {
                description += " - refuted by " + this.props.playerInfos[event.refuter_index].name + " with card ";
                if (isNull(event.refuted_card_index) || isNone(event.refuted_card_index)) {
                    description += "Unknown";
                else {
                    description += cardNameFromCardIndex(event.refuted_card_index).external;
        case "whoOwns":
            let player = "Solution (case file)";
            if (event.player_index < this.props.playerInfos.length) {
                player = this.props.playerInfos[event.player_index].name;
            description = cardNameFromCardIndex(event.card_index).external + " owned by " + player;
    entries.push(<li key={i}>{description}</li>);

The new code is so much more readable! To be fair, some of the refactoring I could have done in JavaScript to begin with, but TypeScript gives me much more confidence to do bigger refactors.

Also, Visual Studio gives me Intellisense and the ability to rename variables and whatnot. I really don’t want to go back to writing JavaScript in a non-IDE!

us-state-map – a React component for a US map of states!

After releasing State Election Map, my first step was to publish a React component with just the map stuff in it. And after messing around for a while with npm and TypeScript and React, I got it working! The us-state-map component is now available on GitHub and npm, and State Election Map uses it. (it includes the map itself and the date slider)

As with whenever I mess around with React I’m pretty sure I’m doing some parts idiomatically “wrong”. (the build step in particular is pretty hacked-together) I like to work on stuff like this to learn how to do things, but it makes me wonder how much I actually learn if I’m just hacking things together and not doing it 100% the correct way. At least it does give me something to copy if I want to do something similar in the future, and I do feel a sense of accomplishment 🙂