Let’s model a carbon nanotube! This post is meant to be a supplemental explanation for the OpenSCAD code I published to parametrically model an armchair carbon nanotube.
While designing a shelf to store my 3D prints, I became fixated on the efficiency and stability of hexagons. I wanted to created another hexagonal structure to organize my desk and thought of a carbon nanotube inspired pen holder. Searching online, I saw several available models, but none that allowed me to parametrically generate the structure. That’s when I thought to create my own parametrically generated carbon nanotube.
First, I need to figure out if the geometry is printable using an FDM printer. In terms of geometry, a carbon nanotube is a wall of tessellated hexagons rolled into a cylinder. Let’s take a look at the regular hexagon to examine the overhangs it forms when printed vertically.
Hexagon Overhang Comparison
There are different angles one can use to roll a graphene sheet into a carbon nanotube. In the armchair configuration, the overhang section bends away from the z-axis at 30° before meeting at a bridge. Not ideal, but I know from my printer benchmarks that it can handle overhangs under 45° and bridges under small distances. In the zigzag configuration, there are no bridges, but the overhang bends away from the z-axis at a 60° angle. It might be possible to print this at a slow speed with active cooling, but to work within the known limits of my printer, I chose to go with the armchair configuration. There’s also a chiral configuration, but the covalent bond angles are much easier to reason with in the armchair configuration.
I wanted to be able to easily adjust my bridge lengths, so I examined the dimensions of a regular hexagon in terms of its edge lengths.
Hexagon Dimensions
This gives us the height and width we need to draw the honeycomb pattern formed by the graphene sheets.
Hexagon Vertex Grid
We can actually fit the vertices into a grid where the the carbon atoms have uniform vertical spacing and are horizontally spaced alternating between whole and half edge lengths. Now, we need roll this sheet into a tube. I wanted my carbon nanotube to have an arbitrary number of faces so let’s take a look the properties of a regular polygon.
Regular Polygon Overhead View
If this was a zigzag configuration, using a regular polygon for overhead view dimensions would suffice because the vertices would be evenly distributed. However, this is the armchair configuration so we need to modify this regular polygon such that edge lengths alternate between whole and half lengths. If we cut off every vertex so that the cut faces form this alternating length pattern, then we will have the shape of the tube from an overhead view.
Regular Polygon Cuts
With these values, we can place the atoms and bonds in position. My initial OpenSCAD implementation threw all the geometry into the workspace and tried to compile them all at once. The preview was fast, but this initial design never finished rendering so I needed to structure my design in a more computationally efficient manner. Through some research, I learned that OpenSCAD allows users to cache geometry for future calls so I added aggressive caching throughout my code. The end result is a model that finishes rendering in under a minute for medium sized models. You can check out the model at Thingiverse.
In my previous post, I outlined a classification system for machinima complexity. The idea of tiers arose from watching a lot of machinima and following production trends in the community. Alongside the existence of tiers, I also hypothesized that machinima production tools grew more complicated over time and that there existed significantly more simple machinimas than technologically sophisticated ones. To quantify this trend, I wanted to classify machinimas by their tiers and then plot how many existed as a stacked bar chart over their release years. This graph never came to fruition because gathering the data for this diagram would be quite challenging. I did learn a bit about computational film analysis in researching how to accomplish my project so I wanted to share my plans anyways. In this technical post, I’m going to explain how I planned to gather data on machinima tiers.
Step 1: Collecting Raw Video Data
Firstly, I need raw video to analyze. Machinima tiers are a label that I contrived so there is no video metadata that will indicate what tier it is. The only way to get a machinima’s tier is to analyze the video myself. Unfortunately, it’s hard to assemble a machinima collection nowadays. Back when I conceived this theory, there existed websites dedicated to hosting gaming content. It was easy to find and download machinima because it wasn’t mixed with non-gaming content. We all assume the internet is forever, but my journey into internet archeology has shown me that’s not guaranteed. Like early motion picture, I suspect many pioneering works are lost to the sands of time. Some common reasons I had difficultly finding works are as follows:
The website that hosted the video is now defunct
YouTube took down the work due to copyright infringement
The video was unindexed or has a very low search relevancy due to its age
Fortunately, I do have some records of these works. Being an avid machinima fan, I kept a catalog of creators I’ve encountered. Some machinimists create more than just machinima so there may be other types of content mixed into their filmography. Thus, to assemble a clean data set, I would need to manually filter through their published works and select the machinimas. It’s tedious work, but there usually isn’t that much to shift through for every machinimist. Being a labour intensive hobby, most machinimists don’t produce that many videos over the course of their career. Using my shortlist heavily biases the data set towards popular English-speaking creators using mainstream games. It’s not representative of the entire community, but this all I have to work with. This bootstrapped data set could then be used to train a bot on the keywords and metadata to target in YouTube searches. Creating the bot, let alone validating it, is a lot of work, but let’s say we overcame this obstacle. How do we process this video data?
Step 2: Video Analysis Tools
We need to gather the tools for video analysis. We can leverage existing computer vision libraries to help us number-crunch pixels. Most of my analysis will strive to use content agnostic processes that can run without needing to do object recognition on game objects. For example, one primary operation I will rely on is frame differencing where we subtract the pixels of one frame from the neighbouring frame to show what is moving.
Original Footage
Frame Differencing Applied
Building on top of this operation, we can divide videos into shots using shot detection algorithms. This will enable us to analyze footage in terms of its cinematic technique. We can use AI to classify types of cinematic shots, but we may need to train it ourselves if models trained on live action data do not generalize to animation. Investigating cinematic technique is important because I theorize that the technically advanced films use a larger variety of shot types than simple films. Assembling these tools will greatly help us scale up our machinima tier pipeline.
Step 3: Identifying Tier Attributes
Each tier has certain characteristics that can be programmatically identified. All of these features are untested and derived solely from my experience with machinima. If a video’s characteristics matches multiple tiers, I will classify it as the highest observed tier because high tier tools build on top of low tier ones.
Tier 0: Gameplay Footage
This is the easiest tier to identify because we can use frame differencing alone. Gameplay footage will have UI elements such as health bars, inventory, timers, etc., on screen for long durations of the video. We can look for outlines of these UI elements by examining the persistent pixels from frame differencing. This will also pick up other video features like watermarks, so we must take into consideration that the UI elements can be partially animated and scattered in various places on the screen. If these persistent pixels are found throughout the video, we can classify the video as gameplay footage.
Tier 1: In-Game Shoots
To tell if a video was filmed in-game, we’ll need to employ some more sophisticated tools to analyze player movements and camera movements. There is a limited palette of motions available to puppeteers. Most games have a set of emote animations the player can use. Beyond that, you are stuck with just the basic motions like running, jumping, and head bobbing. Trying to recognize emotes through humanoid pose estimation would take a lot of effort so I think we should focus on something less game specific. Since camera operators are also a player, we can expect to see camera movement and angles that are normally found in-game. For example, most games have player cameras that cannot do close-up shots. One must use an asset extractor to obtain such a shot. It’s unclear if shot detection algorithms would work on game footage, but if it did, we can expect to see a lot of medium to long shots. The lack of close-ups is a characteristic of tier 1.
The other aspect of camera work that might be noteworthy camera movement. I’ve noticed tier 1 videos tend to use a lot of static shots compared to other tiers because they’re easy to shoot. When the camera does move, however, there isn’t that much variability in speed – it is just the character’s running speed. Moreover, player cameras don’t have the smooth animation paths unlike digitally scripted ones do. If camera solving shows a consistent movement speed, sharp changes in velocity, or any jerkiness, then it’s likely we’re looking at a player controlled camera and can conclude the video is from an in-game recording. As we move into higher tiers, we gain access to more shot types.
Tier 2: Asset Compositing
Extracting and compositing assets into a video gives the director more camera angles and shots to work with. We could examine shots again, but it might be easier to just detect chroma key artifacts. I think the simplest way to define tier 2 is presence of tier 1 attributes with the use of chroma key. If it satisfies the tier 1 filter and uses chroma key, then it can be classified as a tier 2 machinima.
Tier 3: 3D Animation Suites
Directors have a lot of available tools at this tier. Expanding on the importance of camera work, we will set aside the character animations again and focus on the cinematography for clues. In tier 3, all shot types and camera angles are available because the camera can be placed anywhere. I expect to see more close ups and less eye level shots now that the camera is detached from the player. This also means more variation in camera motion. For example, directors can now do slow pans, arc shots, and change focus distance. Lastly, real-time ray-tracing is not common (yet) in games so finding evidence of ray-tracing is a good indicator it was not rendered in-game. Detecting ray-tracing artifacts may become less indicatory as more games adopt next generation graphics, but I still expect cinematographic variety to be a good indicator for tier 3.
Tier 4: Experimental Tools and Mods
This is the most nebulous and rare category. Since I consider motion capture an experimental tool, we can look for its usage by running pose detection and examining the character animation. Multiple body parts moving in unison with natural acceleration and deceleration is a good sign that motion capture is being used. To detect mods, we have to go through the absurdly difficult task of training an object recognition bot on the labeled game asset data, like they do for self-driving cars, to find objects that look like they are part of the game but have a low confidence score. Given how rare tier 3 and 4 machinima is, it might be best to just defer to human judgement and have a reviewer manually label tier 4 machinimas.
Step 4: Plotting the Data
I wanted to draw a chart plotting the growth of machinima communities over time. As time advances, I expect to high tier machinima to emerge after the community hits a certain size. If I graphed the tiers of machinimas created by a community over time, I think the chart would look something like this:
Project Abandoned
As time progressed in my own life, other projects took precedence so instead of building this out, I left this as a write up. I set out to show that my proposed tiers can describe a trend of increasing production complexity in the machinima community. In doing this research, this thought exercise has prompted to think about analyzing videos programmatically. Many movie recommendation algorithms work on film metadata as a proxy for the films’ contents, but not the actual video data itself. I haven’t heard of any recommendation models using computational film analysis as I suspect metadata alone already provides good performance. Nonetheless, there’s many interesting questions about film trends that can be answered by using computer vision techniques to quantify and scale the film analysis. Though I don’t expect anyone to take up my classification system, I hope this post has given you some ideas about computational film analysis.
Note: It will take a little over an hour to watch all videos linked in this post.
Video games are a convenient place to film. There’s no need to rent trucks and expensive camera equipment. Just have your friends log in to your favourite game and meet at the virtual filming location. As long as you can screen capture your game, you can make a machinima.
What is machinima?
Machinima is the art form of making films using video games. The word itself is a portmanteau of machine and cinema. Traditional machinima is essentially an in-game performance filmed using a game’s real-time graphics engine. Machinimists puppeteer game characters and record footage that is then dubbed over in post-production. Over time, machinimists have expanded their toolboxes beyond simple in-game capture to include more elaborate methods of manipulating game assets. This post aims to outline some broad production paradigms, but let’s first provide some motivation.
An example of an Animal Crossing machinima
Why make machinima?
There are many ways to tell a story and film is an effortful way to do so. You can absolutely start shooting with just a modern smartphone, but I’d argue that machinima is an easier approach to film production for the following reasons:
Existing game assets can be selected instead of creating or renting props and sets
Virtual logistics are significantly easier than in real life allowing you to collaborate regardless of geography
Puppeteering is easier than acting so you can recruit fellow gamers into your production crew
Among many reasons, the most notable advantages machinima has are related to its low barriers to entry. Though it’s more accessible than traditional film, it doesn’t mean it’s easy to make. You’re still carrying out the full video production process with some unusual drawbacks.
What are the drawbacks?
There are some critical restrictions on machinima studios:
Machinima is not monetizable because it is derivative work without licensing frameworks
Viewership is limited to game’s player base as machinima seldom appeals to the mainstream
Expressiveness is constrained by the game’s capabilities (e.g. limited character animations)
The nature of machinima being fan labour means this medium will likely fail to gain traction beyond a games’ player base. More importantly, no machinimists can make money from their work because their use of games’ intellectual property is not protected under fair use. Most production teams stop because it’s not possible to financially sustain the project and justify production time. Thus, hobbyists will often use this art form as a stepping stone to greater endeavours. With a few exceptions, machinima has been and will always be a passion project.
As a personal passion, I’ve studied machinima and its methods for a long time. Over the years, I’ve seen many different approaches to get more expressiveness out of game assets. The main motivation for writing this post is to share my framework for organizing these approaches.
Production complexity tiers
I have devised a hierarchy to categorize machinima based on the how advanced their creation process is. I sort videos into their respective tiers based on what I perceive to be the technological complexity of their production pipeline. Each tier builds on the toolbox of the level below it and compounds in difficulty the more one advances. There are no hard boundaries as you can have productions situated between tiers. Higher tier productions are not necessarily better than lower tier ones. They look may more polished, but technical execution is only one aspect of a successful video. My organizational theory is gleaned from years of watching machinima and my own cringeworthy attempts of making them. It has been a useful tool for grouping works with their peers and comparing apples to apples.
Tier 0: Gameplay Footage
Gameplay footage is a precursor to machinima. Unscripted content like let’s plays and e-sports fall into this category. It is raw or lightly edited footage from the player camera that often has the game UI overlaid on top of it. It isn’t until we start using the game as a tool to serve a narrative that we start getting into the first tier.
Tier 1: In-Game Shoots
Traditional machinima is shot in the game environment. The production team puts together costumes and meets at the in-game film location. On set, a player camera captures character actions acted out by puppeteers. The captured footage is then edited in post-production with dubbing from voice actors. This is the most straightforward approach to making a machinima.
Tier 2: Asset Compositing
Machinimists can rip assets from the game and composite them into their video. Often, extracted assets are captured in an asset viewer and then chroma keyed on top of in-game shots. Some machinimists even use solid colour backgrounds found in the game environment to shoot their subjects. Asset viewers are particularly popular for games where no one is allowed to host their own game servers so that film crews don’t need to procure props through the in-game economy. This technique also allows for perspectives of models that are not normally accessible in the game. Beyond this tier, videos become significantly harder to make.
Tier 3: 3D Animation Suites
3D animation suites allow machinimists to tweak all the aspects of their shots. In addition to skeletal animation controls, these programs allow directors to adjust lighting and camera settings. Game assets are imported into a 3D animation tool or virtual studio environment and laboriously animated. The virtual studio environment might utilize the game engine for rendering, but a lot of the advantages of simplicity in traditional machinima are lost at this tier. At this point, machinima is more akin to animation than film.
Tier 4: Experimental Tools and Mods
This tier pushes the limits of machinima. Few have ventured into this territory as it requires a lot of research to carry out. Techniques like using match moving to make a live-action hybrid or motion capture for skeletal animation are rare tools in an animator’s toolbox. Anything involving a mod that alters the game rules or hacks modified assets back into the game would be part of this category because of the technical wizardry required. Each one of these will challenge what you thought was possible from a machinima.
Examples
To illustrate my point, here are some examples videos from each tier for popular games:
The game community makes videos using many creative production methods, but I would not consider them machinima unless they use a game’s visual assets. For example, traditional animation and live-action videos are not machinima even though they use a game’s likeness. They appeal to a similar audience, but their use of the game has more to do with leveraging the games’ conworld rather than using the game software as a storytelling tool. I will acknowledge that this definition does get blurry because some tier 3 machinimas are actually modelled in the likeness of the game with no actual assets being used. If the animation looks like the actual game, I will label it as machinima. Conversely, a machinima does not have to be set in the game’s story universe. All that matters is that the games’ assets are used in the production.
These are arbitrary boundaries I have drawn based on my observations of the machinima community. I had plans to plot a pyramid graph of the tiers to show how the higher tiers tapered off, but the task proved to be too large an undertaking. In a more technical follow-up post, I’m going to outline how I planned to gather these statistics in the hopes that someone else picks it up.
The future of machinima
Machinima will remain a niche art form. Its viewership declines as the player base thins out. It’s inspiring to see small pockets of machinimists still practicing their craft in old games, but they will never receive the same viewership they did at the peak of a game’s popularity. Many move on to pursue more financially sustainable endeavours. Even if licensing agreements were struck, I suspect machinima will have a hard time competing in the attention economy because it is no where near as cost effective as live-streamed game content. Part of the charm of machinima is that almost all of them are passion projects. Nobody makes machinima for profit – they do it to play with friends, sharpen their production skills, garner internet fame, or tell stories they’ve been itching to share.
The growing and waning of machinima communities is inevitable. The next generation of machinimists is making videos right now on the games de jour. I think my organizational theory would still extrapolate out to these new games, but this framework might break with the emergence of new tools for VR and games with cinematic quality graphics. That said, I hope this post gives you some idea of the different ways to tell stories through machinima. I also hope this has potentially sparked a curiosity to watch or make machinima. As long as there are games and the desire to tell stories, there will always be someone making machinima.
To cover a lot of ground in dance class, focus on the number of dance moves explored rather than the distance travelled. In dance, I think of the distance between two positions in terms of the number of moves I make rather than my displacement. A complicated sequence of steps is conceptually longer than a basic promenade that travels the same physical distance. A dance can look like a single chain of moves where each chainlink is a specific action, but what you’re really witnessing is a path through a network of all possible moves for a chosen dance style. The structure of dance starts to take shape when we model dance as a finite state machine.
At first, dance looked like a continuous blur of motion, but, over time, I learned to discretize the blur into individual moves. As my vocabulary of dance moves grew, so did my ability to recognize the words of a kinaesthetic poem. The challenge of dancing is not merely knowing the moves, but understanding how to string them together elegantly. The difficultly of this task had not dawned on me until I reflected on one of the most valuable dance tutorials I’ve ever attended.
It was a quiet Friday evening at the University of Waterloo when I attended one of the UW Breaker’s style development workshops. Most students had left campus for the weekend, but the breakers had gathered for a workshop before the weekly dance session. Today’s lesson? How to keep it fresh.
In hip-hop, being fresh means having novel moves and style. Freshness is respected on the dance floor because it’s a show of skill and creativity. To keep one’s dance looking fresh, the guest teacher gave us seemingly simple advice: “always know three ways in and three ways out”. For any given position, you should know three ways to get into and out of said position. As we randomly picked positions and played with this rule, we soon realized it wasn’t easy to come up with new moves. We spent the entirety of the class inventing, drilling, and discussing ways to transition between positions. As the tiring practise session drew to a close, we sat down and reflected.
During the reflection, one of my classmates mentioned that dance looked like a jigsaw puzzle to him. Not all pieces fit together, but there were particular pieces that just clicked together. For him, there was a particular sense of accomplishment in “solving a dance”. As I grappled with this mode of thinking, the puzzle I visualized faintly resembled some planar graph diagrams I’ve seen in a graph theory course. That’s when it hit me: dancing can be thought of as a graph.
In a dance graph, nodes represent individual moves and the edges represent the transitions between them. Typical nodes are positions and named moves that can be distinctly identified. Edges are movements you make to get to another node. Edges are bidirectional only if you can transition back to the previous position using the same action, but this property is not guaranteed. Some edges are one-way because they cannot be done in reverse. For example, one cannot reverse knee drop because of the power required to overcome gravity on the way up. You must find another edge to transition back to a standing position. A dance can be thought of as a traversal of this graph where the resulting path is the performance you witness.
There appear to be an infinite number of nodes to visit, but, in practise, dancers only work with the subset defined by their school of dance. Within the context of a dance style, there are exists a finite set of valid moves. Membership in this set is sometimes strictly defined like for specific styles in International Standard Ballroom, whereas umbrella categories like hip-hop can contain many sub-styles that are all loosely related by family resemblance. When a dance move happens out of context, like doing a Charleston during a waltz, the invalid move looks very out of place. Without exploring dance taxonomy, we will assume that boundaries exist and that they outline the finite set of moves we want to examine. By narrowing down the universe of valid states a dancer can be in, it makes it feasible to model a dance as a finite state machine.
The topology of a dance graph is shaped by physical constraints and stylistic rules. Some dance nodes form clusters because they’re physically easy to transition between. For example, toprock and floorwork are two large clusters that naturally form in breakdancing because of the energy required to transition between standing and ground positions. Certain dances styles, like ballet, have foundational positions that act as central nodes in the graph. There can also be relatively sparse graphs like in Foxtrot where the style dictates a specific sequence of moves to perform. Each dance style has a unique graph, but so does every dancer trained in the same style.
Dances are unique on a personal level. Though moves are heavily shaped by teachers and peers, dancers must ultimately adapt the dance into movements that best fit their body composition. Height, musculature, centre of gravity, and many additional factors affect how dancers go about executing moves. It is through a combination of external influences and bodily factors that a personal style is created. A personal dance graph encompasses the moves one knows and the sequences one is likely to perform.
Mapping out your dance graph is helpful for introspection into your style. The shape of the graph can tell you a lot about how one dances and areas to focus on. If you notice your dance graph has several poorly connect clusters, you can focus on learning moves to bridge these clusters together. You can also figure out how many steps it takes to reach your signature move from anywhere in the graph. For example, I can traverse the path below, catalog my moves, and then experiment with different shortcuts between these moves. This knowledge is especially useful when your school of dance prizes novelty.
In breakdancing, originality is highly valued. If you are caught copying someone else’s moves, your opponent will call you out with the biting gesture. Accusations of plagiarism are injurious to one’s standing in battle and are thus taken very seriously. Furthermore, if you repeat moves within the same battle, opponents will use the counting fingers gesture to signal how many times they’ve seen you repeat said move. Not only should you not plagiarize other people, but copying yourself makes you unoriginal. With this context in mind, the dance graph framework becomes particularly useful for generating unique paths.
To keep it fresh, mathematically speaking, dancers need to keep traversing unique paths in their dance graph. You can increase the number of unique paths by learning new moves, but a more effective approach is to learn additional transitions between moves you already know. The rationale behind the three ways in and out rule is that it makes your existing graph more connected. Nodes get more edges connecting to other nodes that also receive more edges. If you strictly obey the three ways in and out rule, Menger’s theorem states that you should be able to dance three unique paths between two arbitrary nodes in your graph. I suspect that dance graphs also have some interesting planarity and colouring properties, but I will leave that experimentation as exercise for the reader. The most important exercise for you to complete, though, is to pick positions you know and apply the three ways in and out rule.
As you challenge yourself to find three ways in and out of positions, you will realize that it also helps with style development. When you run out of moves to satisfy the challenge, you start to invent your own moves. This is how your personal style develops. The benefits extend beyond just knowing new moves. Over time, you start to develop hunches about how to find the next puzzle piece. Your approach to making new moves is an integral part of a unique style. However, this advice has limited use for other schools of dance which may have more rigid stylistic rules.
Not all dance genres are as freeform as hip-hop. Some dances dictate specific move sequences to perform. The nature of the dance is reflected in the interesting shapes their graphs take. Through my brief exposure to other styles, I would like to speculate on what some other dance graphs might look like.
If you are a dancer, I would like to see what your dance graphs look like!
As with any abstraction, modelling dance as a finite state machine is reductive. There is much nuance that this model does not capture. For example, it makes no distinction between a move that is performed with an aggressive style and the same move performed in a tight, controlled style. Some forms might not even be describable using a graphical model. One could introduce additional properties, but I will save such complexity for another post.
Dancing is a creative endeavour whose beauty is not just visual, but structural. The structure of your dance is undoubtedly shaped by the move graph you are exploring so it’s important to curate it. As the possibility space of all viable moves collapses into a single timeline, you may notice that some paths are more worn than others. To keep things fresh, try to explore the lesser known paths or, better yet, forge new ones. There is a lot of novelty hiding between the ideas you have not yet connected.
If you lead a busy life, you should learn how to juggle. The physical activity is great for stress relief, but I also mean juggling in the sense of multitasking. Knowing how to efficiently allocate time between tasks is a valuable skill to have. We juggle jobs, tasks, family, and friends as if they were tangible things that we could throw and catch. Though just a figure of speech, delving into juggling as metaphor reveals some interesting ways to think about concurrent tasks.
Juggling, like music, is steeped in patterns that can be described using math. From siteswap to temporal logic, there are many ways to think about juggling patterns. One of the more obscure descriptions I wanted to explore is Shannon’s juggling theorem. I was first introduced to this formula when it was offhandedly mentioned during a weekly juggling session at the UW Juggling Club. The equation is as follows:
(F + D) H = (V + D) B
where
F = Flight time of a ball
D = Dwell time that a ball spends in a hand
V = Vacant time that a hand spends empty
B = Number of balls
H = Number of hands
Formulated by Claude Shannon, this equation describes how the collective time of the balls relates to the collective time of the hands. If we examine one juggling cycle (i.e. one iteration where every ball passes through each hand) and trace through said cycle from the hand and the ball perspective, we can derive the equation. Without the insight to watch just a ball or just a hand, it’s hard to decipher the relationship from merely watching someone juggle.
3 Ball Cascade
I could never fully grasp the equation by juggling until I started to imagine the time values as coloured bars of varying length. To show you what I see, I’ve coded up a visualizer to illustrate the timing of all the juggling events happening in the clip above.
The diagram consists of three ball timelines and two hand timelines.
We can observe that the ball has two states: in a hand and in the air. On a ball timeline, the time a ball spends in a hand (D) is coloured and the time the ball is in the air (F) is left blank. As for the hands, we can observe that it also has two states: holding a ball and empty. When the hand is holding a ball (D), the timeline is coloured using the colour of the ball being held. The rest of the hand timeline is blank (V) meaning the hand is empty.
With this diagram, we can start to play around with the timing relationships. In one cycle, we can see that a ball is thrown and caught once by each hand (i.e. “(F + D) H” meaning a ball trip happens H times) and a hand throws and catches each ball once (i.e. “(V + D) B” meaning a hand trip happens B times). The coloured area in all the ball timelines is equivalent to the coloured area in all the hand timelines because the time a ball spends in a hand is the same as the time a hand spends holding a ball. As we play with this equation, we can see how various aspects of the juggling pattern are temporally related.
If we start throwing the balls higher, the coloured portions of the ball timeline will proportionally shrink as the ball spends more time in the air and, consequently, the hands will spend more time empty.
If we add two more balls, we will see flight times increase because the balls will be thrown higher. On the other hand, there will be less vacant time as the juggler gets busy trying to accommodate the new balls.
This is a neat observation that does not have any practical value, but it is an interesting way to think about juggling. Coincidentally, I learned about Shannon’s juggling theorem around the same time I was attending lectures on concurrent programming. I developed a hunch that juggling and concurrency were related, but didn’t explore the relationship much. It wasn’t until a few semesters later that I was reminded of the topic during a lecture on computer systems performance analysis. The arithmetic used in the lecture felt somewhat similar to the juggling formula so I decided to revisit it.
Let’s reframe the equation I described in terms of computation.
Let’s say there are three threads and two processors.
For simplicity, we can observe that the thread has two states: processing and suspended. On a thread timeline, the time a thread spends in a processor is coloured in and the time a thread is suspended is left blank.
As for the processors, we can observe that it also has two states: processing and idle. When it is processing a thread, I have coloured in the timeline using the colour of the thread it identifies. The rest of the processor timeline is blank meaning the processor is not processing a thread.
The coloured area of all the thread timelines is equivalent to the coloured area of all the processor timelines because the time a thread spends in execution is the same as the time a processor spends processing it.
The concepts map onto this problem domain nicely. You could also apply the math on other scenarios involving two interacting parties. Let’s say there is a group of patients at a hospital that need to go through a fixed set of medical examinations. If you reframe patients as balls and examination rooms as hands, you can start to apply the same intuition to it. However, the equation wouldn’t exactly work in this case because of some assumptions we have made.
Shannon’s Juggling Theorem is a succinct equation because it is meant to describe a cascade pattern where every ball cycles through each hand. It assumes that there is at most one ball in a hand at any given time. The equation does not account for multiplexing where multiple balls are thrown and caught at the same time. Additionally, if we changed the pattern so that some balls are thrown higher than others, then the ball trips would not have a uniform length. Simply multiplying by the number of trips would instead become a sum of all the trip times. Even though the equation requires throws of equal height (i.e. round-robin scheduling) to work, the intuition behind it still holds in the case there balls are thrown different heights.
You could generalize this intuition to any two sided system where each side has a set amount of time interacting and not interacting. This works because of double-counting the set of time from each perspective and equating the two sides. It makes sense when you start manipulating the variables at the aggregate level. For example, if you add more patients to the hospital scenario above while holding the number of examination rooms the same, you will increase the aggregate wait time of the patients. This increase is especially apparent if you view the system from patients’ perspective.
My takeaway from Shannon’s insight is to think in the other perspective. Given what you know about your side of the equation, you might be able to imagine what it’s like on the other side of the system. Whether you’re figuring out multitasking with processors or multitasking with daily life, I recommend thinking not just in terms of the juggler, but also the juggled. Think not only of your schedule, but that of others. Hopefully, this perspective will help you navigate the juggling patterns of life. After all, life is a juggling act.
Additional Reading:
The Science Of Juggling Peter J. Beek and Arthur Lewbel in Scientific American, Vol. 18, Issue 4, pages 92-97; November 1995.
What a familiar bottle. I turn it over in my hands as I meander down the beach. Whatever label it had has washed off long ago. Though the weathered glass exterior, I notice the silhouette of a scroll inside. Something about this object hints at an old memory, but I could not quite place it. To sate my curiosity, I pull out some keys and uncork the bottle. As I invert the vessel, the scroll gently slides out. The paper seems aged, but in otherwise good condition. I slip the string off the scroll and gingerly unravel the paper. A sense of disappointment washes over me as I gaze upon the scroll’s short message. It reads “write a blog”.
Blogging is something I always said I’d do. I’ve accumulated a lot of notes over the years, but never set aside time to polish them into publishable pieces. I’ve told people I would be writing a blog for over a year now, yet still haven’t put anything up. Today, that changes. Today, I post.
This post, along with the many others to come, will be about fairly random subjects. Most of it will be derived from notes I’ve kept on hobbies. I don’t want to turn this into a technical blog, but my current lineup of posts does look rather math related. That said, I’m going to cover a broad range of topics so hopefully, you’ll find some interesting tidbits. I may impart some personal opinions on certain topics, so as a disclaimer, the opinions expressed in this blog are solely my own and do not reflect those of the institutions I am affiliated with. I aim to be informative, but this blog is ultimately meant for leisure reading.
I think this project will be amusing for me to look back on. I used to keep a journal of my personal thoughts, but it devolved into a scrapbook of eclectic ideas over time. I plan to renew my journaling habit and start this parallel stream of public writing. So far, it’s been pretty fascinating to reflect on thoughts I’ve had long ago. Reading a journal is like opening a bottled message sent across an ocean of time. Like my journal, I hope this blog ages just as well. After all, it’s a bottle that anyone can pick up.
With a new bottle in hand, I approach the swash and listen to the incoming waves. I give the bottle one last look and wonder if I’ll recognize it the next time I see it. Perhaps only time will tell. On that last thought, I chuck it out to sea. The bottle plops into the rip current and starts drifting towards the endless horizon. Its journey has begun. Between me and the bottle’s next encounter may be rough waters or calm ones, but, whatever the case, I look forward to seeing it again. Travel far, little bottle. Travel well.
anthologen 