Catsy (amezuki) wrote,
Catsy
amezuki

Math and Lego

Okay, so: I suck at math. This isn't precisely because I lack the aptitude, it's more from a near-total lack of education in anything beyond pre-algebra. You can chalk this up to not paying attention in school, dropping out, and skating by on the GED on the strength of my then-advanced language skills. That was almost 20 years ago, and it still continues to bite me in the ass every now and then.

The first time was a few years after I dropped out, when I was making a half-decent living writing shareware. I needed to plot the distance of a hyperspace route on a simple two-dimensional square grid, and it took someone spelling out the formula before I realized what it meant to calculate the hypotenuse of a triangle, and how to do it. My deficiency in math is one of the biggest reasons I stopped pursuing a career in programming.

Fast-forward to now. What follows is unlikely to interest anyone but math geeks.

First of all, please excuse any awkward or wrong terminology. I am doing my best to describe something far out of my sphere of knowledge for which I may not necessarily know the right terms.

One of the Lego brainstorms I've had on and off involves building a really big colony ship with solar panels of some variety. I had the random idea to try making said array a hex grid--because who doesn't like tilting at windmills? Doing things other than rectangles in Lego can be tough.

What made this idea possible was realizing that I could use this piece at each vertex of the hex grid, with the size of the hexes determined by the length of the elements I use to connect them. The problem: this piece is neither common nor cheap. The cheapest I found it in any bulk on Bricklink was around sixty cents apiece. So rather than indiscriminately ordering a pile of parts, I set about trying to calculate how many I would need.

Ever try to count the vertices in a large hex grid? Good luck doing it by eye. Thus began my long journey of trying to come up with a formula for calculating the number of vertices in any hexagonal area of a hexagonal grid for n, where n is the length in hexes of each face of the area in question.

First I tried cutting the area in half, since there would be an equal number of vertices in each half if you drew an imaginary line corner-to-corner across the area, perpendicular to the faces of the individual hexagons through which the line is drawn. I reasoned that if I could solve for half of the area, I could solve for the entire area. Each "row" of hexes in the half is one greater in length than the previous row the closer it gets to the center, so I figured there must be some kind of set progression that would give me the answer.

I could easily get the number of vertices in a parallelogram with each face being the same number of hexes, so I thought perhaps if I did that and then found the number of hexes remaining in that half of the hexagon, I could calculate the remainder from there. I was so close to the answer!

The problem arose when I realized what the progression was. Take an area 5 hexes long on a side. Use a game map to visualize if you need to. Now cut it in half, and block off a 5x5 hex parallelogram, leaving a triangular arrangement of hexes remaining. Okay, fine--now I need to know the number of hexes in that remainder area, so I counted them visually. For an area with 2 hexes on a side, the remainder is 1 hex. For an area 3 hexes on a side, the remainder is 3 hexes. For 4 hexes on a side, the remainder is 6. For 5 on a side, the remainder is 10. For 6 on a side, the remainder is 15.

What I realized was that the number of hexes in triangular remainder area was n - 1 + r, where n is the number of hexes per face of the hexagonal area, and r is the remainder for an area n - 1 hexes on a side. In other words, in order to find the remainder for n, I had to already know the remainder for n - 1. To find the remainder for n - 1, I had to already know the remainder for n - 2. And so on. It's a progression similar to, but not, a Fibonacci sequence.

I could solve this programmatically using a FOR loop without any trouble. But I had no idea how to find a formula for doing so. Searching turned up nothing of use.

Ultimately, I realized that I was completely overthinking this. Instead of dividing the hexagonal area in half, I tried dividing it into equilateral triangles. Once I did that and counted the number of vertices in each triangle, I found the answer. For a hexagonal area n hexagons on a side, the number of vertices is 6 * n².

The kicker? Learning this effectively rendered this project dead in the water. At 60 cents apiece, there's no way I'm constructing even a simple grid 6 hexes on a side--not when that would require 216 of the "vertex" pieces.

So much for that idea. But I learned cool new maths.
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 1 comment