nickplaysjazz

A Retrospective on The Elder Scrolls Adventures: Redguard

2026-08-29T05:00:00.000Z

Since it's release in 2011, The Elder Scrolls V: Skyrim has played such a pivotal role in the cultural zeitgeist that it effectively defined what an RPG/action-adventure title even looks like. I'd argue that it wasn't until 2023 when Baldur's Gate III released that we saw a significant innovation in this type of title, although certainly it wasn't the only critical addition to the genre in the meantime. Regardless, everyone is waiting now to see what Bethesda is going to cook up with The Elder Scrolls VI. For better or for worse, it's going to define Bethesda the same way that Grand Theft Auto VI defines Rockstar.

Now, I am a big fan of retro video games and, in particular, old-school RPGs. It's a good time to investigate the origins of The Elder Scrolls, and I have a lot to say on the matter. The first two games in the series—The Elder Scrolls: Arena in 1994 and The Elder Scrolls II: Daggerfall in 1996—are in a lot of ways nearly a different series than what we would recognize as "The Elder Scrolls" franchise starting with The Elder Scrolls III: Morrowind in 2002. These first two games deserve a deep dive, one I'm not ready to get into today. Instead, what I want to investigate is one of the oft-forgotten spin-offs of the franchise: the 1998 action-adventure title The Elder Scrolls Adventures: Redguard.

I'm writing this post not just simply as a review of Redguard, although I will be sharing thoughts on the game and how it plays in 2026. What I really want to convince you of is something that I realized while playing Redguard: that this game was the moment the franchise became what fans recognize as "The Elder Scrolls" today.

The Gameplay

Unlike the mainline Elder Scrolls titles, Redguard is not a first-person RPG with action-adventure elements. Instead, this game is a third-person action-adventure game where you play as a pre-written character. There are no skills nor experience levels, and the gameplay is limited to a single hand-crafted island instead of the sprawling open-world provinces of the mainline games. The game is fully voice acted, something that will sound surprising to anyone used to Morrowind's later text-based dialogue.

At the time of Redguard, it was conceived that the Elder Scrolls franchise would feature three product lines: the mainline games would be known as "Classics," "Legends" would be about specific historical moments in Tamriel, and "Adventures" would be more adventure and character focused (see more info on the UESP). For the "Legends" line, we got the dungeon-crawler An Elder Scrolls Legend: Battlespire in 1997. Then came Redguard in 1998. Both sold poorly, and future planned installments for the "Adventures" line—Eye of Argonia and Paradise Sugar—never materialized, despite some minor hints for sequels in Redguard.

You end up with this odd duck of a game. It's a game that clearly wants to define a new direction for the series, to make the Elder Scrolls into a franchise instead of just a series of open-world RPG titles. But it's also a game that's completely unlike anything else in the series, and as a result there's no comparisons to be made.

For example, I have some difficulty discussing whether or not the combat system was a good choice for the game. Is it a good combat system? ...No. You can swing your sword, block, and strafe around opponents. You end up kind of awkwardly shuffling behind opponents while holding the block button to try to smack their back with your saber, and the camera will more often than not swing around you such that the enemy falls out of your line of sight. It's not difficult so much as clunky, and it fails to deliver on the swashbuckling pirate fantasy that the game promises.

But was the new combat a good choice for the series? Was it a step in the right direction? That's the question I have difficulty answering. It's a system that was, unfortunately, never iterated upon. I can identify some roots of something enjoyable here, something that could be improved upon. In fact, and this might be controversial, but I think swordplay in The Elder Scrolls VI might actually stand to benefit from looking in Redguard's direction! Skyrim has an infamously slippery melee combat experience. You swing a sword and it just kind of paddles an enemy until they ragdoll at death. I think some more dynamic swordplay involving slashes vs. jabs vs. blocks could be a fruitful ground for experimentation.

The healing mechanics are fine. There's no natural health regeneration; you have to use a health potion or pay the town priest to heal you. Redguard throws so much coin and potions at you that I never felt in danger so long as I entered combat at high enough health. There's two other potions in the game that provide defense and attack bonuses, but they aren't really all that useful. In fact, I guess there's supposed to be an in-game alchemy system, but I never once heard about it!

The game has an unusual difficulty curve. There are challenging portions of the game, but it's never consistent. You don't experience a direct ramp up in difficulty from the beginning of the game to its end. In fact, one of the very first major quests you complete turns all the patrolling guards in the game hostile to you. This makes exploration and walking through the town extraordinarily tedious, and I'm frankly shocked the development team stuck with this decision. It's really unfortunate that one of the primary sources of combat in the game exists primarily to slow the player down. Guards are going to be your number one enemy type in the game, and not by a small amount.

The RPG exploration in the game was very satisfying for me. I was able to play the game organically, without my eyes on the wiki to find the next quest (something I think is a little more difficult to honestly do in, say, Daggerfall). Only once did I have to consult the wiki to find the way forward. Otherwise, the game is pretty good at naturally directing you to the quests you need to think about. You need to talk to folks and pay very close attention to everything they say.

My favorite RPG experience was when I needed to find the password to the secret gambling den in town. Earlier, the silversmith told me that Lakene lost his wife's silver locket gambling with Rollo. Rollo won't give it up to me—I'll probably have to steal it from him, which I won't mind since he's a jerk—but I did find out from the general store owner that Rollo leaves his house to bring cargo from the docks when ships come in. Prnell (yes, his name is spelled "Prnell") waves the flag to signal the bell tower when a ship comes in; he will let me wave the flag if I find his eyepiece. He also told me he's friends with the bell tower operator, and that's where you'll spot his eye piece. It's a complicated chain of events in this quest, one that might overstay its welcome with some folks since it only involves talking. But I got a great sense of satisfaction when all the talking to the townsfolks paid off all at once!

I should briefly mention the soundtrack, which consists of merely seven songs and clocks in at 17 minutes. "Main Theme" is a jaunty, adventurous tune. "Valour & Honor" sticks out as a kind of upbeat battle/dungeon theme. You'll hear the other songs rotate out throughout the island, and boy will you become familiar with them. They're all fun and well-made, but they grate on the nerves by the end of your run. I ended up muting the game, tired of hearing the same songs. But I would nevertheless love to see the motifs from these songs make a reappearance in any future Elder Scrolls game taking place in Stros M'Kai.

A final note on the gameplay: the game is not stable. It's the kind of game that you'll want to be tapping the quicksave button often so that recovery from crashes doesn't sting so badly. The game is not optimized well, which led to very jumpy FPS even on a modern computer. There are apparently two graphical versions of the game, but I played with the original, low res version of the game through Steam. I wish all the success in the world to the Redguard Unity port for stability and gameplay enhancements, especially since Redguard isn't too large of a game.

The Story

To fans of the Elder Scrolls, you may be surprised to learn that Redguard does not take place in the Third Era of Tamriel, but actually in the Second Era during Tiber Septim's conquest of Tamriel. This age is famous for the formation of the Septim Empire that exists within all the mainline games (at least until Skyrim, taking place after a time jump of 200 years). Redguard takes place after a civil war in Hammerfell between the Crowns and Forebears. The Forebears gained a pyrrhic victory by allowing the Empire to take over Hammerfell in return for military support against the Crowns.

You play as Cyrus, a swashbuckling mercenary who is headed home to Hammerfell after many years away. Cyrus is arriving at the island of Stros M'kai to find his lost sister Iszara. Stros M'kai was the site of the recent defeat of the Crown Prince A'tor by Emperor Tiber Septim's dragon Nafaalilargus, and tensions between the defeated Crowns and Imperial Forebears remain high.

Does that sound like a lot of lore to dump on you all at once? I thought it was. It is also all delivered to the player in a single opening cinematic to the game. Complain all you want about the heavy-handed and lengthy Skyrim introductory sequence—at least the developers learned to show and not tell.

The characters of Stros M'kai are quite varied and unique. Cyrus is a daring, no-nonsense, sarcastic adventurer who hides a heroic heart underneath the veneer of a mercenary. It's funny to learn about his character as you play through his actions. Cyrus' interview with Provisional Governor Richton will always end in Cyrus mouthing off and earning a battle with the palace guards. There is no other outcome here, no way to sweet talk the governor into letting you go. Cyrus will be a smart-ass, and you, the player, will deal with the consequences.

The other main characters are also memorable. The voice acted characters are all quite developed personalities despite their short screentime, if a bit flat in development over the course of the story. There's the pompous Richton, the Provisional Governor of Stros M'kai. There's Tobias, your old Nord captain who hangs out at the tavern to offer you advice, his take on local politics, or to laugh about old escapades. There's a creepy-looking Sload necromancer named N'Gasta with permanently exposed gums. Mainline Elder Scrolls fans may recognize a recurring in-game esoteric book called "N'Gasta! Kvata! Kvakis!" authored by him. Sloads are fairly mysterious in the greater Elder Scrolls lore, so I was surprised that one just pops up as a character all the way back in Redguard. In any case, all these characters feel a bit to me like a game of Dungeons & Dragons, where your DM builds on some archetypal characters and throws a quirk or two on top to distinguish them.

The Book

By far the most interesting part of Redguard's contribution to the greater Elder Scrolls lore, though, isn't even found in the game itself. The game ships with a book (or pdf) called "The Pocket Guide to the Empire". This booklet is well-worth a read for anyone who is interested in the Elder Scrolls. It is a trove of world development.

The writers of this book (along with the major game developers for Redguard) are household names for serious Elder Scrolls fans. Todd Howard, Michael Kirkbride, Kurt Kuhlmann, Ken Rolston, and many others contributed significantly. The "Pocket Guide" really started the Elder Scrolls as we recognize it today. Kurt Kuhlmann even said that Redguard was his favorite game that he worked on!

Redguard is where we get a lot of deep lore about Tiber Septim. The game introduced soul gems, which feature a large part in the magic systems of all the later games. The specific accents that Khajiit and Argonians have, and their tendency to speak in third-person, started in Redguard. We first see the steampunk visual of Dwarven ruins in Redguard (although this would really be developed in Morrowind). There's so many bits of recognizable Elder Scrolls that can be traced back to Redguard. You'll even recognize some voice actors; the voice actor for Cyrus, Michael Mack, would go on to be the male Redguard voice actor in Morrowind and Oblivion.

The Elder Scrolls series before Redguard, back when Julian LeFay was the biggest single influence, was a procedurally generated dungeon-crawler. Those games are most reminiscent of other 90s-era CRPGs. But with Redguard, we see a turn in Bethesda's development towards hand-crafted worlds, with a bigger emphasis on world-building.

Conclusion

I hope that I've shown you that Redguard merits a little more credit within the Elder Scrolls community. I'm surprised it doesn't get much more discussion other than as a fun fact, that there are these oddball spin-off games that never went anywhere.

I don't think I'll play Redguard again, at least not any time soon. It's not a game that lends itself super well to replayability, and it's not a fantastically executed game, particularly in 2026. If you are a big fan of old-school RPGs and enjoyed Arena or Daggerfall, you'll want to take a look. In any case, I think that, for whatever else you may think about Redguard, its role as the initiator of the modern Elder Scrolls franchise should be recognized.

Predicting Eclipses

2026-07-09T05:00:00.000Z

I've been sharing a lot about astronomical calculations lately. In a previous series of posts (see the first post), I created a clock to show the positions of the planets down to an accuracy of the arc-minute.

I've worked out another fun astronomical calculator. This time we are predicting when and where eclipses are visible on Earth. See my GitHub repository that contains the code for this.

We have already determined how to calculate the geocentric positions of the planets. All we need is the ecliptic longitude, ecliptic latitude, and physical distance of the planets, the end-products of our previous calculation. Now, eclipses can only occur at syzygy of the Earth, Moon, and Sun; that is, when all three lie in a straight line.

Note that a syzygy can only occur when the Moon is a full Moon or a new Moon. This happens precisely when the Sun and Moon share the same ecliptic longitude; that is, the horizontal coordinate lines up. But for a syzygy to take place, the vertical coordinates of the Sun & Moon, the ecliptic latitudes, must be sufficiently close together!

Great! Let's start by finding the dates of new Moon & full Moon. In our code, we scan once per day across a year to see the difference in ecliptic longitude between the Moon and the Sun. (Really, I think you'd only need to do this once roughly every two weeks since that's the rate of change between a full Moon & new Moon, but there's no benefit to be had here. The calculation is rapid.)

When the difference between the two longitudes changes signs, we know we are at a full Moon or new Moon, and an eclipse may occur. If this difference changes at 0 degrees, then a new moon is occurring, and a solar eclipse may occur. If this difference changes from -180 to +180 degrees, then a full moon is occurring, and a lunar eclipse may occur. Once we have found a potential syzygy occurring on a day, we use a more accurate root-finding method to determine the exact time that the ecliptic longitudes are equal.

We know the Sun & the Moon are horizontally aligned. Are they close enough vertically for an eclipse to take place? Denote the ecliptic latitude of the moon as $\beta$ . Our goal now is to calculate a maximum "pocket" of latitude $\beta_{max}$ within which an eclipse is visible.

Finding the Maximum Ecliptic Latitude for an Eclipse

We want to find the maximum latitude $\beta_{max}$ where either:

(for a lunar eclipse) the shadow cast by the Earth hits the Moon, or
(for a solar eclipse) the shadow cast by the Moon hits the Earth.

Let's denote the "angular radius" of the Moon and Sun as $r_{moon}, r_{sun}$ . This number represents the angle covered on the celestial sphere by that body. For the sun, this is $r_{sun} = \arcsin{\frac{SUN\ RADIUS}{SUN\ DISTANCE}}$ . The "horizontal parallax" of the Moon and Sun will be $\pi_{moon}, \pi_{sun}$ . That's the scaling of the planetary body size due to how close we are to that body. This is actually equal to the angular size of Earth viewed from the target body, so it has the same form as before. For the sun, it is $\pi_{sun} = \arcsin{\frac{EARTH\ RADIUS}{SUN\ DISTANCE}}$ .

Let's start with the solar eclipse. If we were at the center of the Earth, the eclipse begins exactly when the Moon touches the Sun. That's $r_{sun} + r_{moon}$ . On the Earth's surface, parallax makes the Moon appear larger (making it easier for an eclipse to occur) and the Sun appear larger (making it harder for an eclipse to occur). In other words, $\beta_{max} = r_{sun} + r_{moon} + \pi_{moon} - \pi_{sun}$ .

Let's take this one step further to determine the type of solar eclipse:

If $\beta \leq \beta_{max}$ but $\beta > r_{moon} - r_{sun} + \pi_{moon} - \pi_{sun}$ , then the Moon only grazes the edges of the Sun. This is a partial solar eclipse.
Otherwise, the Moon is crossing the center of the Sun. When $r_{moon} \geq r_{sun}$ , we have a total solar eclipse. Otherwise the Moon doesn't completely cover the Sun and we get an annular solar eclipse.

Now for the lunar eclipse. The "umbra" is the dark center of the shadow cast by the Earth, where the Sun is totally obscured. The "penumbra" is the lighter outer shadow, where the Sun is only partially obscured. It turns out that $R_{umbra} = \pi_{moon} + \pi_{sun} - r_{sun}$ and $R_{penumbra} = \pi_{moon} + \pi_{sun} + r_{sun}$ . A lunar eclipse occurs exactly for the condition $\beta_{max} = R_{penumbra} + r_{moon}$ .

But again, we can classify the types of lunar eclipses:

If $\beta \leq \beta_{max}$ yet $\beta > R_{umbra} + r_{moon}$ , then the Moon never enters the umbra. This is a penumbral lunar eclipse.
Otherwise if $\beta \leq R_{sumbra} + r_{moon}$ but $\beta > R_{umbra} - r_{moon}$ , we have a partial lunar eclipse, where only a portion of the Moon enters the umbra. Otherwise, we have a total lunar eclipse.

Fantastic! We can now predict when an eclipse occurs (its moment of syzygy) and classify its type. But a remaining interesting question is where are these eclipses visible?

Predicting the Location of Eclipse Visibility

It is much simpler to predict the visibility of lunar eclipses than solar eclipses, so let's start there. Lunar eclipses happen over a very large area. Anyone who can see the Moon sees the eclipse. In our script, we will do one simple calculation: at the precise moment of syzygy, determine the visibility of the Moon across the entire globe.

Now, calculating when the Moon is visible is not exactly trivial, but it's somewhat routine. See Paul Schlyter's detailed explanation of this calculation; it's the same thing we'd use if we wanted rise and set times of the planetary body. In our case, we are calculating the altitude of the Moon for a given latitude & longitude on the globe, and if this altitude is above zero, then the Moon is above the horizon, and the lunar eclipse will be visible. We do this for a grid of points across the globe.

I didn't concern myself with the movement of this lunar eclipse as it forms, so there are areas outside the envelope of visibility at the time of maximum eclipse that will see the lunar eclipse as it's forming but won't be so noted on our map.

The solar eclipse is significantly more involved. We know the time of the maximum eclipse, but we want to see the path of totality as it sweeps across the globe. Here's the general way I handled this:

Sweep across a 5-hour window centered around the time of maximum eclipse in 5 minute increments.
At the given time, for every point on our grid of latitude and longitude on the globe, calculate the Sun's altitude. If the Sun is below the horizon, skip this location; the Sun is not visibile, and it's nighttime there.
Otherwise, at the given latitude and longitude, calculate the topocentric Right Ascension and Declination of the Moon. This is very similar to the geocentric calculations we already have, but it accounts for the small shift in the Moon's position due to our position on the Earth's surface. Paul Schlyter already has explained how to do this calculation.
Calculate the angular separation $\theta$ between the Sun and the topocentric position of the Moon. Using the same boundaries we described earlier, we can determine if $\theta$ shows we are in the path of totality or within the envelope of partial solar eclipse.

The path of totality is a really tight path. In fact, I went ahead and subdivided my grid points on the globe when we are checking for totality; if any part of the grid point is in the path of totality, we mark the whole cell on our map as lying within the path of totality.

An Example Using the Code

Let's use our code to see what eclipses are going to happen next year in 2027. Take a look at the GitHub repository to use it yourself.

We see four eclipses will occur. (Actually, we missed a penumbral lunar eclipse taking place on 2027-07-18. But the eclipse is so comically shallow that I'm not upset that I missed it.)

Scanning for eclipses one year forward from: 2027-01-01 00:00 UTC
+---------------------+-------------------------+
| Date (UTC)          | Type                    |
+---------------------+-------------------------+
| 2027-02-06 15:55:14 | Annular Solar Eclipse   |
| 2027-02-20 23:19:59 | Penumbral Lunar Eclipse |
| 2027-08-02 10:06:03 | Total Solar Eclipse     |
| 2027-08-17 07:31:51 | Penumbral Lunar Eclipse |
+---------------------+-------------------------+

Report successfully saved to 'eclipse_report.txt'.

In eclipse_report.txt we have more detailed information about where these eclipses are visible. Professional eclipse predictions are by Fred Espenak, www.EclipseWise.com. These images are used with permission.

First we compare the annular solar eclipse taking place on 2027-02-06.

And also we can compare the penumbral lunar eclipse taking place on 2027-02-20.

The accuracy of these paths looks satisfyingly close! I'm very pleased with the results we have here. Let me know what you think in the comments and if you'd like to see more astronomical calculations in the future.

An extra note. If you're astronomically inclined, you may notice that I have left out one detail. Our earlier calculations for planetary positions use UTC for time, but for the precision needed for accurate eclipse predictions, we need to use terrestrial time (TT). These two are different due to the cumulative difference between the fixed-length day and the rotation of the Earth. The difference $\Delta T$ is fit by a complex piecewise polynomial presented by Espenak and Meeus. The uncertainty in this value is very low for the modern age (on the order of fractions of a second), but eclipse predictions with this tool will not be very good the further you get from today. For comparison, in 2026, $\Delta T$ is roughly 70 seconds; ignoring this shifted the locations of my eclipse predictions nearly a quarter of the way around the globe!

Making an Astrological Clock V

2026-06-21T05:00:00.000Z

This article is the fifth of a series where I build a digital clock to show real-time astronomical locations of planetary bodies.

In my first post, we wrote a script to calculate astronomical positions of the seven classical planets. In my second post, we verified the accuracy of the results of these calculations versus high-quality scientific data. In the third post we turned our astronomy measurements into astrology terms along the zodiac. Finally, in my fourth post we got an Arduino running a simple clock. See my GitHub repository that contains the code for this project.

Today is an exciting day, because we finally will pull everything together! First we will talk about the code for calculating the planet's positions, then we will talk about the astrological glyphs. And then we will show off a working product.

Calculating the Planet's Positions

The code to calculate the planet's positions is largely identical to the Python code we built previously. There are only a handful of changes I want to point out, but take a look at the GitHub repository if you are interested in more details.

In the first place, the Arduino Nano only has 2 kB of dynamic memory. Furthermore, our 128x64 pixel display uses up 1 kB of that dynamic memory! That means we have to be really careful about how we store the doubles that are our orbital elements. It actually worked out that, rather than calculating and storing the doubles the entire time, we just recalculate them every time we need them. It saves us a lot of space and it's not a pricey calculation.

// the orbital elements for the seven classical planets, dependent on julian day d
void get_orbital_elements(int it, double d, double &N, double &i, double &w, double &a, double &e, double &M) {
  switch(it) {
    case 0: N = 0.0; i = 0.0; w = 282.9404 + 4.70935e-5 * d; a = 1.000000; e = 0.016709 - 1.151e-9 * d; M = 356.0470 + 0.9856002585 * d; break;
    case 1: N = 125.1228 - 0.0529538083 * d; i = 5.1454; w = 318.0634 + 0.1643573223 * d; a = 60.2666; e = 0.054900; M = 115.3654 + 13.0649929509 * d; break;
    case 2: N = 48.3313 + 3.24587e-5 * d; i = 7.0047 + 5.00e-8 * d; w = 29.1241 + 1.01444e-5 * d; a = 0.387098; e = 0.205635 + 5.59e-10 * d; M = 168.6562 + 4.0923344368 * d; break;
    case 3: N = 76.6799 + 2.46590e-5 * d; i = 3.3946 + 2.75e-8 * d; w = 54.8910 + 1.38374e-5 * d; a = 0.723330; e = 0.006773 - 1.302e-9 * d; M = 48.0052 + 1.6021302244 * d; break;
    case 4: N = 49.5574 + 2.11081e-5 * d; i = 1.8497 - 1.78e-8 * d; w = 286.5016 + 2.92961e-5 * d; a = 1.523688; e = 0.093405 + 2.516e-9 * d; M = 18.6021 + 0.5240207766 * d; break;
    case 5: N = 100.4542 + 2.76854e-5 * d; i = 1.3030 - 1.557e-7 * d; w = 273.8777 + 1.64505e-5 * d; a = 5.20256; e = 0.048498 + 4.469e-9 * d; M = 19.8950 + 0.0830853001 * d; break;
    case 6: N = 113.6634 + 2.38980e-5 * d; i = 2.4886 - 1.081e-7 * d; w = 339.3939 + 2.97661e-5 * d; a = 9.55475; e = 0.055546 - 9.499e-9 * d; M = 316.9670 + 0.0334442282 * d; break;
  }
}

Our device uses 7-bit units to store data. I worked out the approximate accuracy loss that storing our Julian day d in this format gets us. I believe it's accurate down to about 30 seconds or so. Remember when I said we wanted to be accurate to 1-2 arc-minutes? That will work out fine if we are off on the time by 30 seconds. But it's a fundamental limitation of our device, and as a result I won't bother updating the screen more than once every 30 seconds.

The other oddity you might pick out in the code is how we store strings. Since these strings are static, we can store them in the 30 kB of flash memory rather than using up precious dynamic memory. The syntax gets a little odd, but it saves us a lot of space; the strings eat up our dynamic memory very quickly.

const char sun[] PROGMEM = "SUN";
const char mon[] PROGMEM = "MON";
const char tue[] PROGMEM = "TUE";
const char wed[] PROGMEM = "WED";
const char thu[] PROGMEM = "THU";
const char fri[] PROGMEM = "FRI";
const char sat[] PROGMEM = "SAT";

const char* const daysOfTheWeek[] PROGMEM = {
  sun,
  mon,
  tue,
  wed,
  thu,
  fri,
  sat
};

// string buffer needed to store strings before printing
char buffer[24];

// when we need to print, we use the following
strcpy_P(buffer, (char*)pgm_read_ptr(&(daysOfTheWeek[weekday])));
display.print(buffer);

Astrological Glyphs

At the smallest text size, each character is 5x7 pixels, with 1 pixel of horizontal spacing between each character. I was able to sketch some 5x7 planet glyphs that I was satisfied with.

The zodiac signs were a little harder, and I decided to increase the size slightly to 7x7 pixels for these glyphs. This is the only way I was able to get Capricorn or to distinguish Virgo and Scorpio.

The Working Product

After all our work, we can finally display our finished product. Here I've set the clock to Central Daylight Time.

I'm very happy with this product. It fits my original specifications very well! I can see the arc-degree and arc-minutes of each planet within each zodiacal sign, and I can see the current weekday, date, and time. The symbols look fine on the screen, about as legible as the text surrounding. I confirmed by hand once more that all of our positions are accurate to +/- 1 arc-minute here. Fantastic!

The table may not be the most graphically creative approach, although it's my favorite. As an alternative, I have sketched up two other prototype designs. The first is a more traditional wheel shape. I don't display the position in arc-degrees here, and the planetary symbols get a little messy when overlapping, so I didn't opt for this approach.

The other alternative, perhaps a bit cleaner, is a "squared" horoscope wheel. In this example, I am just putting the planetary symbols in one of 12 boxes along the rim of the display. This leaves the center for the date and time.

All three of these are in the GitHub repository as separate scripts if you would like to use them.

Future Improvements

If we wanted to take this further, I have a few notes. I tried to display when a planet was in apparent retrograde motion (maybe with an "R" on the display), but we simply are out of program space. We are using up about 85% of the flash memory now, so we'd likely need to upgrade to a bigger Arduino for that calculation. Now, we could opt to solder the connections and mount the entire product in a plastic box. I might end up doing this, and I'll be sure to update with another post if I do. You could also add an on/off switch, which would be very helpful to prevent burn-in of the pixels on the screen.

Otherwise, that about wraps up this project. Thanks for reading this far, I'm pretty happy with how it turned out!

Making an Astrological Clock IV

2026-06-14T05:00:00.000Z

This article is the fourth of a series where I build a digital clock to show real-time astronomical locations of planetary bodies.

In my first post, we wrote a script to calculate astronomical positions of the seven classical planets. In my second post, we verified the accuracy of the results of these calculations versus high-quality scientific data. In the third post we turned our astronomy measurements into astrology terms along the zodiac. See my GitHub repository that contains the code for this project.

Today we are going to set up a clock using an Arduino Nano. This will serve as our design for the astrological clock that we will make in the next post.

First thing is our shopping list. I'm not including any plastic casing or soldering while we design a prototype. I did not have any wiring or breadboards on hand, so this shopping list is inclusive of all the bits you will need. Pulling a working digital clock together for a unit cost of less than $20 is pretty neat!

Part	Total Cost	Units	Unit Cost	Notes
Nano V3.0 ATmega328P Micro-Controller	$15.09	3	$5.03	LAFVIN brand. Comparable device to Arduino Nano. Comes with three USB Type-A to Mini USB cables.
DS3231 Real Time Clock Module	$8.29	3	$2.76	AITRIP brand. Did NOT come with batteries, Amazon listing was incorrect.
3V CR2032 coin batteries	$4.99	4	$1.25
OLED SH1106 OLED Display Module 1.3 inch	$17.99	5	$3.60	Hosyond brand. 128 x 64 pixels
Breadboard	$6.68	6	$1.11	Deyue brand
Jumper wire kit	$11.99	n/a	n/a	Austor brand
TOTAL:	$65.03		$15.86	Using two breadboards, estimating $1 for jumper wires.

The wiring for this design is very simple. You'll see a very similar design for a number of "Arduino clock" designs around. I've built a simple diagram with TinyCAD, which is free, open-source, and runs in your browser.

Image built using TinyCAD, licensed under CC0 Creative Commons Public Domain

In brief, the GND pin on our RTC module and OLED display module gets hooked up to GND pin on the Arduino; we do the same for the VCC pins on each module to the 5V pin on the Arduino. Our modules communicate via the I2C Protocol, which is pins A4 & A5 on the Nano. The SDA pins on the modules go to pin A4, and the SCL pins on the modules go to pin A5.

Here's what my wired prototype looks like:

Now for the software. Again, there's a number of designs for Arduino-based clocks online, but I'll attached the version I wrote below (and on the GitHub repository so you can test this design if you use it). I won't go into detail on the code, but notice that I've included a TIMEZONE_OFFSET_HOURS variable. If you want the time in UTC (as we will for our astrology calculations), you will need to offset your local time to UTC time. For instance, if you are in Washington, D.C., currently in Eastern Daylight Time = UTC-4, you would set this variable to a value of -4 if you want to display UTC.

#include <Wire.h>
#include <Adafruit_GFX.h>
#include <Adafruit_SH110X.h>
#include <RTClib.h>

#define SCREEN_WIDTH 128
#define SCREEN_HEIGHT 64
#define OLED_RESET -1

Adafruit_SH1106G display(SCREEN_WIDTH, SCREEN_HEIGHT, &Wire, OLED_RESET);
RTC_DS3231 rtc;

const int TIMEZONE_OFFSET_HOURS = 0;

const char* daysOfTheWeek[7] = {
  "SUN",
  "MON",
  "TUE",
  "WED",
  "THU",
  "FRI",
  "SAT"
};

void setup() {
  // DS3231 rtc module
  Serial.begin(9600);

  if (! rtc.begin()) {
    Serial.println("Couldn't find RTC");
    Serial.flush();
    while (1);

  }

  if (rtc.lostPower()) {
    // sets the RTC to the date & time this sketch was compiled
    // you should run this once outside the "if" block when you replace the battery
    DateTime localCompileTime = DateTime(F(__DATE__), F(__TIME__));
    uint32_t utcTimestamp = localCompileTime.unixtime() - (TIMEZONE_OFFSET_HOURS * 3600);
    rtc.adjust(DateTime(utcTimestamp));
  }

  // SH1106 oled module
  display.begin(0x3C, true);
  display.clearDisplay();
  display.setTextSize(2);
  display.setTextColor(SH110X_WHITE);
}

void loop () {
  DateTime now = rtc.now();

  display.clearDisplay();
  display.setTextSize(1);
  display.setCursor(0, 0);
  display.print(daysOfTheWeek[now.dayOfTheWeek()]);
  display.print(" ");
  display.print(now.year());
  display.print("-");
  if (now.month() < 10) display.print("0");
  display.print(now.month());
  display.print("-");
  if (now.day() < 10) display.print("0");
  display.print(now.day());
  display.print(" ");
  if (now.hour() < 10) display.print("0");
  display.print(now.hour());
  display.print(":");
  if (now.minute() < 10) display.print("0");
  display.print(now.minute());
  //display.print(":");
  //if (now.second() < 10) display.print("0");
  //display.print(now.second());
  
  display.display();

  // update once every 30 seconds
  delay(30*1000); 
}

Compiling and loading this onto the Arduino gives us a succesful clock! It correctly reports the time, which was 2:40pm local time on Sunday June 14, 2026. We can unplug & replug it in as desired, and it continues ticking at the correct time. Also, instead of running connected to a computer, you can connect the USB end to a standard USB charging block operating at 5V.

In my next post, we are going to put this all together. We have the time calculated, now we just need to perform the astrology calculations on-board the Arduino and display them. I expect the biggest obstacle will be graphical design, not the calculations, but we will see!

Making an Astrological Clock III

2026-06-08T05:00:00.000Z

This article is the third of a series where I build a digital clock to show real-time astronomical locations of planetary bodies.

In today's post we are going to map our astronomical position calculations into the terms of astrology. We've done the hard work up front for this post. Consider again our orbiting body around the sun:

Lasunncty at the English Wikipedia, CC BY-SA 3.0, via Wikimedia Commons

We calculated previously the right ascension of a planet, that is, the longitude and latitude of the planet in reference to the equator on Earth. That's what you'd use if you wanted to point a telescope at a point in the sky.

However, astrologers are interested in the position of the planets versus the ecliptic, the plane that contains the orbit of the earth around the sun. That's different from the plane of the equator! The image I showed above does a good job highlighting this. The spin of earth around its axis defines the equator, a plane like the yellow plane, but the orbit of earth around the sun defines the ecliptic, the gray plane. We need to rotate our positions onto the ecliptic. See also this Wikipedia page for more info.

Fortunately, we already calculated this in our code! We have the geocentric ecliptic coordinates already, calculated along the way towards our equatorial coordinates. I've moved some code around and created a second script in the GitHub repository that will calculate the zodiacal planetary positions for a given time, but it uses the same mathematics that we were using previously. No extra math needed.

Now we have a horizontal position in degrees across the ecliptic, but we need to express this in astrological terms. Instead of a degree from 0 to just below 360, we now define signs every 30 degrees. The first sign, starting due east, is Aries, which will go from 0 degrees to 29.99... degrees. The next sign, going from 30.00 degrees to 59.99... degrees, is Taurus. And so we go on, next for Gemini, Cancer, Leo, Virgo, Libra, Scorpio, Sagittarius, Capricorn, Aquarius, and finally Pisces. I'll also convert this into degrees and arc-minutes, as that's more traditional.

It's interesting to note that since astrologers couldn't get the positions of the planets accurate down to the arc-minute, they historically leaned towards placing emphasis on the degree in the sign alone. This is partially why I decided our clock should be accurate to the arc-minute rather than aiming for higher accuracy.

So for our test date of June 4, 2026 CE at 12:00 UTC we get the following:

+---------+-----------+----------+
|  Planet |      Sign | Position |
+---------+-----------+----------+
|     sun |    gemini |  13° 54' |
|    moon | capricorn |  29° 08' |
| mercury |    cancer |  04° 53' |
|   venus |    cancer |  19° 31' |
|    mars |    taurus |  12° 20' |
| jupiter |    cancer |  24° 44' |
|  saturn |     aries |  12° 30' |
+---------+-----------+----------+

Great! We have the positions of the planets in basic astrological terms.

We already know these numbers are correct since we validated the planetary positions in the last post, but just for completion let's compare our results to an astrology program.

I can recommend the Astrolog program, open-source and free from a lovely Geocities-like website. Thanks to Walter D. Pullen for working on this program. I had lots of fun generating all sorts of data and images with this program. After noodling around, we get the following astrology wheel, showing the planets in their signs, along with a lot of data I'm going to ignore.

If you look on the center-right, you will see the readouts of the positions of the planets, which I've summarized in the table below.

Planet	My Calculations	Astrolog Calculations
sun	gemini 13° 54'	gemini 13° 53'
moon	capricorn 29° 08'	capricorn 29° 07'
mercury	cancer 04° 53'	cancer 04° 52'
venus	cancer 19° 31'	cancer 19° 31'
mars	taurus 12° 20'	taurus 12° 20'
jupiter	cancer 24° 44'	cancer 24° 44'
saturn	aries 12° 30'	aries 12° 31'

Once more, we confirm that our data is within 1 arc-minute or so of more trustworthy sources. (I had Astrolog use the Swiss Ephemeris, which is evidently today's state-of-the-art data for astrologers.)

On our next post we will break out the electronics and begin building our clock.

Making an Astrological Clock II

2026-06-07T05:00:00.000Z

This article is the second of a series where I build a digital clock to show real-time astronomical locations of planetary bodies.

To recap my first post, we laid out some goals for the project and calculated astronomical positions of the seven classical planets for a provided time. You can check out my GitHub repository that contains the code for this project.

Today we will try to verify our calculated astronomical positions versus high-quality scientific data. This is actually a bit more difficult than it seems, though not impossible if you are willing to pay close attention to details.

The foremost source for information on planetary positions is the Horizons System offered by NASA's Jet Propulsion Laboratory. This is a set of very precise ephemerides (astronomical positions) fit to astronomical observations. Furthermore, you can easily access the data through a web browser. You can also query the system through an API or command-line interface, but for today we won't need any of the stronger capabilities.

What we want to obtain from the Horizons System is the geocentric position of the planets—that is, the position of the planets relative to the Earth's center, not relative to some point on the Earth's surface, which is the topocentric position of the planets.

In the Horizons System, I use the following settings, which I'm posting here for replicability:

Ephemeris Type: Vector Table.
The Coordinate Center is Geocentric [code: 500].
The Time Specification is e.g. 2026-06-04 12:00 UT.
The Table Settings. The reference frame is ICRF. The reference plane is the equatorial (not ecliptic!) reference frame. We apply no light-time or aberration-corrections to the vectors, i.e., we want the geometric states.

If we run this for e.g. Saturn, then in the output text we can see the following.

*******************************************************************************
$$SOE
2461196.000000000 = A.D. 2026-Jun-04 12:00:00.0000 UTC 
 X = 9.684482405935125E+00 Y = 2.072149975806727E+00 Z = 4.694613587831113E-01
$$EOE
*******************************************************************************

We convert this into a right ascension in degrees via atan2(X,Y), 12.07 degrees. But the right ascension for Saturn we got previously was 12.39 degrees! What's the issue?

Correcting for Precession

Earth's axis of rotation rotates relative to the fixed stars at a very slow period of ~25,000 years. This is the so-called precession of the equinoxes. Our code using Paul Schlyter's calculations gives us the planetary positions for the "equinox of the day"; that's what we will want for astrological purposes.

However, the NASA JPL Horizons System reports for what is known as the J2000.0 epoch. In other words, the positions we have calculated for 2026 CE must be rotated along the ecliptic to the year 2000 CE for comparison with the Horizons System data. The difference is not negligible, even for only 26 years difference!

Paul Schlyter shows us that, rather than applying a rotation matrix, we can make a simplified fix (see section 8 of his notes for details). I've updated the GitHub repository accordingly; you can enable a flag in the main() function to correct to a given epoch.

Let's take our calculated planetary positions, express them in terms of the J2000.0 epoch, and compare that to the NASA JPL Horizons System data. I want to re-iterate that the values we use in our astrological clock will NOT be corrected to a J2000.0 epoch; we want the equinox-of-the-day values. But for the purposes of comparison, we need to apply this correction.

Planet	My Calculated J2000.0 RA	NASA JPL Horizons System RA
sun	72° 08'	72° 08'
moon	301° 31'	301° 29'
mercury	95° 00'	95° 00'
venus	111° 02'	111° 02'
mars	39° 43'	39° 44'
jupiter	116° 21'	116° 21'
saturn	12° 03'	12° 04'

Spectacular! This is exactly what we are hoping to see: our calculated right ascension values are within 1-2 arc-minutes of the NASA dataset! How satisfying to see. We could do the same for the declination, but I'm confident at this point that we can trust our calculations.

In my next post we will map our planetary positions into astrological terms.

Making an Astrological Clock I

2026-06-04T05:00:00.000Z

This article is the first of a series where I build a digital clock to show real-time astronomical locations of planetary bodies.

I first had this idea when playing Kerbal Space Program, which got me interested in how astronomers predict & measure the positions of the planets. I ended up writing a python script to do this, and I thought a fun application of this script would be to put the planetary bodies in terms of astrology.

This first post will be on how we mathematically predict the planetary bodies positions. Later posts will cover converting this to astrological terms and designing and building the clock.

I am not an astronomer by trade, but I'll try to summarize briefly the relevant science upfront. We know from Kepler's laws, later derived from Newton's laws of motion, that the movement of two planetary bodies follows an ellipse. We can define this mathematically with six independent terms, called the orbital elements. It's easier to see an example rather than explaining each of them.

Lasunncty at the English Wikipedia, CC BY-SA 3.0, via Wikimedia Commons

In a perfect world, given a specific time, these constant orbital elements would determine the positions of the planets exactly. However, due to gravitational perturbations by other planetary objects and the effects of general relativity, these orbital elements change slowly over time. The modern solution is to measure the positions of the planets and fit an equation to describe the orbital elements over time; this equation will be valid for some determined degree of accuracy and for some determined length of time.

Goals for the Calculations

Let's define some goals:

Positions are calculated for the seven classical planetary bodies alone: Mercury, Venus, Mars, Jupiter, Saturn, the Sun, and the Moon.

Traditional astrology utilizes only these bodies to begin with. That's plenty to work with. We will just neglect Uranus and Neptune along with Pluto and the other dwarf planets for now. In any case, they move extremely slowly, which is not so interesting on a clock.
Positions should be accurate to roughly $\pm$ 1 arc-minute when compared with high-quality planetary position data.

How accurate is this? The fastest moving planetary body here is obviously the Moon, which has a "sidereal" period of 27.321661 days (that is, a full circle travelled around the earth relative to the stars, not the time from new moon to new moon, which would be a "synodic" period of 29.53 days). 1 arc-minute is therefore traversed by the Moon on average in 1.82 minutes. Our clock could be off by, at worst, roughly 2 minutes.

We will see when we get to the astrology that the arc-degree is more important. The moon travels one arc-degree on average in 1.82 hours. So certainly an error of $\pm$ 2 minutes of time for the fastest moving planetary body will satisfy an astrologer.
Positions only need to be accurate for roughly 1900 CE to 2100 CE.

I do not care if this clock outlasts me.
Positions are not obtained not via lookup tables ("ephemeris" tables) but from calculations.

On one hand, it's no fun to just reference a big table of planet positions over time. On the other hand, when we get to the building of the digital clock, we are going to be using very small computer memory chips. There will be no room for storing large datasets!

Performing the Calculations

Great news: the hard work has been done for us! A fantastic write-up by Paul Schlyter explains how to perform these calculations in great detail. The accuracy is indeed 1-2 arc-minutes, and the formula will be valid for many years (an error of roughly 7 arc-minutes for the Moon in 1000 years). It fits our use case exactly.

I don't want to re-invent the wheel, since Paul Schlyter already did such a great job explaining everything. Let me just highlight what the general algorithm looks like here:

Calculate the "day number," which converts the year, month, date, and UTC time into a single decimal number.
Calculate the six orbital elements as a function of the day number.
Use the orbital elements to calculate the Cartesian position of the planetary body relative to Earth, also as a function of the day number.
Map the Cartesian position of the planet onto the celestial sphere. This gives us the "Right Ascension" (eastward direction relative to the equator) and "Declination" (northward angle relative to the equator). These numbers are what you would use if you wanted to point a telescope at a planetary body.

The Code

I've created a astronomy-calculations GitHub repository that I'll use for this project.

Just to show off the results of the code so far, here's what we find for the planetary positions for June 4, 2026 CE at noon UTC:

Calculations for: 2026-06-04 12:00 UTC
+---------+----------+----------+
|  Planet |   RA (°) |  Dec (°) |
+---------+----------+----------+
|     sun |  72.5381 |  22.4654 |
|    moon | 301.9089 | -23.0753 |
| mercury |  95.4145 |  25.4792 |
|   venus | 111.4463 |  23.9720 |
|    mars |  40.0928 |  14.9775 |
| jupiter | 116.7463 |  21.5835 |
|  saturn |  12.3947 |   2.8487 |
+---------+----------+----------+

Keep an eye out for my next post, where we will try to validate this code.

The 2026 Vegetable Championship

2026-05-27T05:00:00.000Z

Today I'm happy to announce the results of the 2026 Vegetable Championship.

This single-elimination tournament featured 64 vegetables and near-vegetables (i.e., for our purposes here we went with tomato as a vegetable). A number of beans also ended up on the bracket to fill out some space. Initial placements within the bracket were determined randomly. Around seven votes were cast per vegetable face-off, voted on a whiteboard in my office.

There were no pre-determined criteria for how one should vote. One person may have voted due to preference of taste while another person voted based on versatility of the veggie across many dishes.

The initial pool of vegetables turned out quite diverse, featuring classics like broccoli, uncommon veggies like parsnips, and a handful of esoteric ones like kohlrabi. Overall the tournament covers a broad range of the typical western diet.

The irony does not escape me that in our tournament of vegetables, it came down to a battle of starches: potato vs. sweet potato. Potato packs quite a punch, when you consider mashed potatoes, fried potato, potato starch, potato soup, cubed potato in stews.... It has certainly earned its victory. I do wish that some of the healthy green veggies made it further in the bracket, though.

The relative merits of onion, tomato, and garlic were debated very heavily in the office. These ended up fighting against each other for a spot in the semi-finals. Tomato beat out onion, which surpised me; I had figured since onion went in so many dishes, it would've carried this fight. In the end, tomato took the win and only lost to potato for the championship seat.

Corn got beat very early by an unfortunate seeding next to garlic. That's a tough break. I think corn could have definitely gone further with a little more luck early on.

I've got two major gripes. Chickpea vs. sweet potato, for me at least, would be chickpea every time. I love chickpeas. They are a great neutral bean if you need to add protein to a meal. Plus you get hummus from chickpeas. My other disagreement is with the sweet potato v. bell pepper matchup. Although sweet potato was the victor here, I think bell pepper is a great addition to most meals. Onion + bell pepper + garlic is the starting formula to many dishes I make. I eat bell pepper way more often than I have sweet potato, so this match seemed like a bit of an upset.

Otherwise I'm not too surprised by the rest of the results. Veggies like daikon, water cress, bamboo shoots, etc. just don't have the versatility or recognition that the veggies we see in our Sweet 16 have.

Anyways, congrats on the win, potato. I guess I'll roast some potato to celebrate.

The 3B1B String Problem II

2026-05-25T05:00:00.000Z

This is Part II on a math puzzle posted by 3Blue1Brown. You see the intro to the problem here.

You have a box filled with $n$ strings. You randomly select the end of one string and tie it to the end of another randomly selected string. Sometimes you'll pick up a string and its own end, meaning you'll tie a loop. Other times, you'll just tie together two strings into one longer string. Either way, you'll eventually end up with only loops of strings. After tying together all ends, what is the average number of loops you will have if you start with $n=50$ strings?

In Part I, we derived that the number of loops $a_n = \sum_{k=0}^{n-1}\frac{1}{2k+1} = 1 + \frac{1}{3} + \frac{1}{5} + \cdots + \frac{1}{2n-1}$ is, for large $n$ , $\approx \ln (2n - 1) - \frac{1}{2} \ln (n - 1) + \gamma/2$ with $\gamma\approx 0.577$ the Euler-Mascheroni constant. Hence $a_{50} \approx 2.938$ loops.

In this post, we are going to support our answer with some Monte Carlo sampling. This approach is pretty simple. We will use a Python simulation to act out the structure of tying our strings into loops, measure the number of loops we get, and repeat the simulation many times. The average number of loops should statistically agree with our previous answer.

I thought it would be fun to use an LLM to get the code started. It's a great use case for an LLM to define some efficient code, particularly since we have an expected answer with which to compare. The LLM that I used identified disjoint-set data structures as an efficient way to store our data, so that's what we will work with.

Let's start with the main code block. No surprises here, just setting up the trials and reporting statistics after we are done.

import numpy as np

if __name__ == "__main__":
    N_STRINGS = 50
    TRIALS = 10000

    results = [run_trial(N_STRINGS) for _ in range(TRIALS)]

    # calculate & print important statistics
    mean_val = np.mean(results)
    std_dev = np.std(results)
    standard_error = std_dev / np.sqrt(TRIALS)
    ci_margin = 1.96 * standard_error

    print(f"Mean Loops: {np.mean(results):.4f}")
    print(f"Std Dev: {np.std(results):.4f}")
    print(f"Std Error: {standard_error:.4f}")
    print(f"95% Confidence Interval: [{mean_val - ci_margin:.4f} to {mean_val + ci_margin:.4f}]")

The run_trial() function makes use of a DisjointSet() data structure that we will define shortly. It will keep track of the strings that are still in use.

def run_trial(N):
    strings = DisjointSet(N)
    ends = list(range(N)) * 2
    num_loops = 0
    current_pool_size = len(ends)

    for _ in range(N):
        # select on end randomly
        it1 = np.random.randint(0, current_pool_size)
        str1 = ends[it1]
        ends[it1] = ends[current_pool_size - 1]
        current_pool_size -= 1

        # select another end randomly
        it2 = np.random.randint(0, current_pool_size)
        str2 = ends[it2]
        ends[it2] = ends[current_pool_size - 1]
        current_pool_size -= 1

        # tie strings together, potentially forming a loop
        if strings.find(str1) == strings.find(str2):
            num_loops += 1
        else:
            strings.union(str1, str2)

    return num_loops

Let's take a small example, e.g. 5 strings. Then ends = [0, 1, 2, 3, 4, 0, 1, 2, 3, 4] initially. We pick an end randomly, say it1 = 7. Then ends[it1] = 2, that is, we have picked the second end of string with ID 2.

What's going on with ends[it1] = ends[current_pool_size - 1] and current_pool_size -= 1? This is a really neat trick that saves us loads of computer time. The obvious thing to do after we have picked & tied a certain string end would be to remove it from the list entirely. Unfortunately, constantly resizing lists ends up being computationally expensive. In this LLM-generated solution, we set ends[it1] to the final value of the array, and then decrement current_pool_size by 1. In effect, we have replaced the old string end with some other value, and we ignore one spot on the list. No list resizing on the fly at all. A smart move by the LLM!

So how do we keep track of the strings as a disjoint set?

class DisjointSet:

    def __init__(self, n):
        self.parent = list(range(n))

    def find(self, i):
        path = []
        while self.parent[i] != i:
            path.append(i)
            i = self.parent[i]
        for node in path:
            self.parent[node] = i
        return i

    def union(self, i, j):
        root_i = self.find(i)
        root_j = self.find(j)
        if root_i != root_j:
            self.parent[root_i] = root_j
            return True
        return False

Initially, strings is a list from 0 to n. As strings are tied together, these values in the list will be replaced by some representative "parent" string value. The find() method does exactly that, telling us what the parent node is. (Incidentally, as another time-saving trick, the parent nodes are updated during this find() method to speed up the next time we need to find a given parent!). The union() method uses these parent nodes to lengthen the string.

Now with all the preliminaries out of the way, how does the code perform? For 50 strings and 10,000 trials, $a_{50}=2.9496 \pm 0.0131$ . Our value of $a_{50} = 2.938$ falls within this 95% confidence interval. Great! Our results agree very well, and further trials don't give significantly improved results.

Furthermore, keeping the number of trials constant at 10,000, our theoretical solution agrees really well with simulations as you change the number of strings. Surprisingly, even at as low as $n=5$ strings, our approximate solution works really well!

That's a wrap on this problem. A bit of fun looking at it from two different angles—theoretical and numerical—to be confident in our solution.

The 3B1B String Problem I

2026-05-23T05:00:00.000Z

A recent math puzzle posted by 3Blue1Brown caught my attention. You see the intro to the problem here; I'll summarize below. Spoilers ahead if you want to give it a shot yourself.

Imagine you have a box with $n$ strings. You randomly select the end of one string and tie it to the end of another randomly selected string. Sometimes you'll pick up a string and its own end, meaning you'll tie a loop. Other times, you'll just tie together two strings into one longer string. Either way, you'll eventually end up with only loops of strings. The question is: after tying together all ends, what is the average number of loops you will have if you start with $n=50$ strings?

I started out by doing some calculations for small $n$ by hand. For $n=1$ , you can only end up with 1 loop. For $n=2$ , once you select your first end of a string, there are 3 ends remaining; there is a $\frac{1}{3}$ chance of making a self-loop, and a $\frac{2}{3}$ chance of making one long string. Either way you'll end up with 1 string left, and that reduces to our $n=1$ case. Similarly, for $n=3$ , there is a $\frac{1}{5}$ chance of making a self-loop, and a $\frac{4}{5}$ chance of making a longer string; either way, you reduce to the $n=2$ case.

$n$	Average number of loops $a_n$
1	1
2	$\frac{1}{3}(1+a_1)+\frac{2}{3}(a_1) =\frac{4}{3}$
3	$\frac{1}{5}(1+a_2)+\frac{4}{5}(a_2) =\frac{23}{15}$
4	$\frac{1}{7}(1+a_3)+\frac{6}{7}(a_3) =\frac{176}{105}$

It becomes pretty clear that this obeys a recursion relation:

\begin{equation*}\begin{split} a_1 &= 1 \\ a_{n+1} &= \frac{1}{2n+1} \left ( a_n + 1 \right ) + \frac{2n}{2n+1} a_n = a_n + \frac{1}{2n+1} \end{split}\end{equation*}

No doubt one could prove this rigorously via induction. How do we get this in explicit terms? As it turns out, there's a neat trick for solving recursive arithmetic sequences.

\begin{equation*}\begin{split} a_{n+1}- a_{n} &= \frac{1}{2n+1} \\ \sum_{k=1}^{n-1} \left ( a_{k+1} - a_{k} \right) &= \sum_{k=1}^{n-1} \frac{1}{2k+1} \\ a_n - a_1 &= \sum_{k=1}^{n-1} \frac{1}{2k+1} \\ a_n &= \sum_{k=0}^{n-1}\frac{1}{2k+1} = 1 + \frac{1}{3} + \frac{1}{5} + \cdots + \frac{1}{2n-1} \end{split}\end{equation*}

Since we sum up

(a_1 - a_0) + (a_2 - a_1) + (a_3 + a_2) + \cdots

on the left hand side, most of the terms disappear! We end up with a nice sum to evaluate in terms of the number of strings

n

We could stop here, but we can do better than a very long series. Consider the harmonic series $H_n = \sum_{k=1}^n \frac{1}{k} = 1 + \frac{1}{2} + \frac{1}{3} + \cdots + \frac{1}{n}$ . As $n\rightarrow \infty$ , the partial sum $H_n \rightarrow \ln n + \gamma$ , with $\gamma \approx 0.577$ being the Euler-Mascheroni constant. Our sum looks very much like the harmonic series, but we need to get rid of the even terms.

Some manipulation with indices gets us what we need:

\begin{equation*}\begin{split} H_{2n-1} &= 1 + \frac{1}{2} + \frac{1}{3} + \cdots + \frac{1}{2n-2} + \frac{1}{2n-1} \\ \frac{H_{n-1}}{2} &= \frac{1}{2} \left ( 1+\frac{1}{2} + \cdots + \frac{1}{n-1} \right ) = \frac{1}{2} + \frac{1}{4}+\cdots + \frac{1}{2n-2} \\ \Rightarrow a_n &= H_{2n-1} - \frac{H_{n-1}}{2} \end{split}\end{equation*}

We want the solution for $n=50$ strings, a relatively large number. It's probably justified to use the harmonic series partial sum. For large $n$ ,

\begin{equation*}\begin{split} a_n &\approx \ln (2n - 1) + \gamma - \frac{1}{2} \left ( \ln(n-1) + \gamma \right ) \\ a_n &\approx \ln (2n - 1) - \frac{1}{2} \ln (n - 1) + \gamma/2 \end{split}\end{equation*}

For $n=50$ strings, we expect on average to have $a_{50} \approx 2.938$ loops. If you were to perform the whole sum by hand, you get $a_{50} = 2.938$ . (Our approximation agrees up to the 5th significant figure.)

Since our solution grows logarithmically, you can fill the box with enough strings to get any arbitrary number of loops on average after our tying procedure. However, the number of strings quickly becomes ludicrously large. For instance, if you wanted to get on average $a_n=50$ loops after our tying procedure, you must start with a box that has on the order of $10^{43}$ strings!

Stay tuned for Part II of this post, where I will be doing some Monte Carlo simulations to measure the solution to this problem statistically and compare it to our theoretical answer.

Welcome to nickplaysjazz!

2026-05-21T05:00:00.000Z

Hello! If you're reading this, then you have found my new blog: nickplaysjazz. I'm hoping to use this blog to share fun projects I'm working on in science, computer programming, and retro gaming. I've got a lot of different hobbies, so you should expect a good mix of content on this blog.

You can learn a little about me or see some of my recent finds on this site.

Subscribe to my RSS feed using your favorite RSS feed aggregator to stay tuned. Thanks for stopping by!