Heatmaps of Different Keyboard Layouts

Most people use QWERTY as their keyboard layout. I did too, until about one year ago. Over the past year, I’ve tried both Dvorak and Colemak. I’ve gotten to about 60-70 WPM on all three of these layouts, and after that I feel that typing speed doesn’t really matter much anymore—especially if I’m coding and I’m spending most of my time thinking instead of typing. But I still like Dvorak and Colemak better than QWERTY because they are more comfortable. I think I’ll stick with Colemak, since it’s more similar to QWERTY, and I want to be prepared for situations where I may be forced to use a QWERTY keyboard.
I wanted to create some visualizations to make the benefits of Dvorak and Colemak more apparent. Here are some heatmaps I generated in Python using numpy and Pillow. These are based on the frequency of letter usage (data from Wikipedia). Red corresponds to more frequently used areas, and blue corresponds to less frequently used areas.

QWERTY

Colemak

Dvorak

Pretty cool, huh? You can see that clearly, Colemak and Dvorak allow you to stay on the home row (the middle row) far more than QWERTY does. QWERTY just has your fingers going all over the place.

The math behind the heatmaps

I actually generated the pixel data for the heatmaps using my own algorithm, since I thought it would be fun. I don’t actually know how heatmaps are typically generated, but maybe it’s somewhat similar to this. I’ll explain the math I used.
So here’s the information I started with:

• $n=26$, the number of keys on the keyboard
• $(x_i, y_i)$ for $i=0,1,\ldots n-1$, the pixel coordinates of key $i$
• $f_i$, the frequency of usage of key $i$ (i.e. the proportion of all letters that this letter makes up)

The goal is to assign a number to each point $(x,y)$ on the plane corresponding to the intensity of that point in the heatmap. One obvious way to go about this would be to go through each $i$ from 0 to $n-1$, and then color the point $(x_i,y_i)$ with intensity $f_i$—then for any remaining points, color them with intensity 0. However, this would make for a rather boring diagram, since only single hard-to-see pixels would be colored, and most of the diagram would be zeroes. So, I came up with a better way.
I needed a way for keys to color the points closer to them with a higher intensity than points farther away from them. For this, I used something similar to a Gaussian PDF. I used this formula to determine how much key $i$ should color point $(x,y)$:
$$f_ie^{-0.003\left((x-x_i)^2+(y-y_i)^2\right)}$$
To break this down, the term $(x-x_i)^2+(y-y_i)^2$ represents the squared distance between the point to color and the key in question. When we multiply by -0.003 (a completely arbitrary constant that I fould worked well) and then exponentiate it, we get a term that peaks at $(x,y)=(x_i,y_i)$, but then tapers off to 0 uniformly in all directions as it gets farther and farther from $(x_i, y_i)$. Then we multiply it by $f_i$, since we want more frequent keys to have more intensity than less frequent keys. I then summed these terms over all $i$ to get my final calculation:
$$\sum_{i=0}^{n}f_ie^{-0.003\left((x-x_i)^2+(y-y_i)^2\right)}$$
This is what my program calculated for every point in the image. It then converted it to an appropriate RGB color, and saved the image as a PNG so that I could see it!

Written with StackEdit.

Installing Swift 3.0.2 on Ubuntu on Windows 10

I followed the instructions at the Swift download page in the Linux section. I used the “Swift 3.0.2 RELEASE - Ubuntu 14.04” download. This environment variable remembers the location where I downloaded it.

export SWIFT_ROOT=$HOME/swift

Hello world works

At this point, I can run a simple hello world program. I created a file called hello.swift with the following contents:

print("Hello world")

Then I ran it as such:

swift hello.swift

As expected, it printed hello world.

Executable stack issues

But then I found that I wasn’t able to use the package manager to build an existing Swift package called LogicSim that I created on my Mac, which worked there. When I went to that directory and ran swift build, I got the following error:

/home/anoop/swift/usr/bin/swift-build: error while loading shared libraries: libFoundation.so: cannot enable executable stack as shared object requires: Invalid argument

The fix

Apparently that error is caused by some flag in the shared object ELF file libFoundation.so. To clear it, I ran the following commands

sudo apt-get install execstack
sudo execstack -c $SWIFT_ROOT/swift/usr/lib/swift/linux/libFoundation.so

That fixed the above error, but…

Operation not permitted errors within .build folder

Now when I try swift build I get these errors

warning: minimum recommended clang is version 3.6, otherwise you may encounter linker errors.
Compile Swift Module 'LogicSim' (4 sources)
<unknown>:0: error: error opening '/mnt/c/Users/anoop/GoogleDrive/Swift/LogicSim/.build/debug/LogicSim.build/Module~partial.swiftmodule' for output: Operation not permitted
<unknown>:0: error: error opening '/mnt/c/Users/anoop/GoogleDrive/Swift/LogicSim/.build/debug/LogicSim.build/Port~partial.swiftmodule' for output: Operation not permitted
<unknown>:0: error: error opening '/mnt/c/Users/anoop/GoogleDrive/Swift/LogicSim/.build/debug/LogicSim.build/AndGateModule~partial.swiftmodule' for output: Operation not permitted
<unknown>:0: error: error opening '/mnt/c/Users/anoop/GoogleDrive/Swift/LogicSim/.build/debug/LogicSim.build/main~partial.swiftmodule' for output: Operation not permitted
<unknown>:0: error: build had 1 command failures
error: exit(1): /home/anoop/swift/usr/bin/swift-build-tool -f /mnt/c/Users/anoop/GoogleDrive/Swift/LogicSim/.build/debug.yaml

The fix

I didn’t really know why this was happening. I suspected bad permission bits in the directory, since it resides on my C: drive, inside my Google Drive folder, which was being synced from when I worked on it on my mac. I just removed the build directory and tried again:

rm -r .build
swift build

Surprisingly, the build succeeds without errors!

I also ran the executable to make sure it works as expected, and it did.

.build/Debug/LogicSim

Written with StackEdit.