It turns out you can buy little cubes of various elements from sketchy Amazon marketplace vendors.

Naturally, I wanted some Tungsten, because of its incredible density.

Previously, in July 2021, I had tried to remove garbage collection from the possible variables affecting my iterative mergesort. I transliterated the Go code to a plain C version that could not have any garbage collection. The C code benchmarked very similarly to the Go code.

As a way to see if merely accessing the linked list node’s memory causes the mergesort performance drops, I wrote two non-sorting functions and benchmarked them to try to distinguish

• accessing the nodes’ data
• modifying .Next pointers

I read JRR Tolkien’s The Hobbit for the first time since at least Junior High, or maybe even before.

I finally read the copy of The Mueller Report Illustrated that someone gave me a while back. I think this is just the obstruction of justice investigation. I was dreading the bad memories it would inevitably dredge up.

My PowerBall and MegaMillions winnings for second quarter of 2024: $0.00

For 2024 year to date: $0.00

Problem statement

This problem was asked by Cisco.

Given an unsigned 8-bit integer, swap its even and odd bits. The 1st and 2nd bit should be swapped, the 3rd and 4th bit should be swapped, and so on.

For example, 10101010 should be 01010101. 11100010 should be 11010001.

Bonus: Can you do this in one line?

I’ve been commuting somewhat less than 3 days a week, from Fort Collins to Denver and back. I’ve seen some mighty strange stuff.

I thought that since the purely recursive implementation of mergesort didn’t show weird, abrupt performance drops, traversing linked lists (no matter what order the nodes appeared in memory) also did not show abrupt performance drops, and that node size in memory caused different performance oddities, that the iterative implementation’s memory access patterns might be the cause.