nickplaysjazz

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!