Animations

We’ve got some unique animations, coded by me but with direction from Josh

Stars

Waves

Fireworks

Of course, the lights can just be on, or we have a preset that puts them on a dim orange setting to promote sleepiness.

App

The lights are controlled with an app we’ve codenamed Lite Brite. You can get to the controls on the lock screen. The left side controls the living room and the right buttons control the bedroom lights.

[Lock Screen Lights]

Inside the app you can also set an alarm time. When the alarm goes off the lights in the bedroom slowly turn on and then begin to flash.

[Full App]

Components

The living room has 10 meters of LEDs. They are the NeoPixel LEDs from Adafruit.

The LEDs are controlled by a Raspberry Pi which is running the custom software. It communicates with a server (written in Go and hosted by Heroku) so we can change the lights even from outside the apartment. It it fun to change the lights and try to find our window on the skyline.

Extra Fun

After a vacation to The Wizarding World of Harry Potter was cancelled, I put in our own magic. There is a Harry Potter wand which recognizes gestures and acts just like a TV remote. By adding an infrared sensor to the Raspberry Pi, it can receive commands from the wand.

[Wizard video]

Josh’s latest request is to endow a gavel with the powers of Mjölnir. We will see where that goes…

One amazing part of mathematics is that the laws are universal. You don’t need to be told that for every circle \(\frac{circumference}{diameter} = 3.14159....\), because you can discover it yourself. If we met aliens, we’d expect they’d have discovered these same truths. Kinda crazy!

Doing real math is discovering and proving new relationships. Doing math in a classroom is not like this at all. Could we set up students to discover these laws for themselves?

I’ve created a few puzzles in NumberPad for discovering these universal truths independently. I’m inspired by video games which put you on the right path and give just enough clues, but still have you feeling 💃😁🎉 when you solve it.

(If you haven’t read about NumberPad yet, check out this previous post to see the basics. This post will be a lot more interesting with that context.)

For this puzzle, pretend you don’t know that you haven’t learned about \(\pi\) yet. Let’s discover it.

We’ve got a circle. You can change the diameter:

You can play with the circumference, and try to make it match up with the circle. When it does match up, it turns dark blue.

The point of this puzzle is to figure out the relationship between those two numbers so that it will work for every circle. NumberPad only supports addition, multiplication, and exponentiation, so let’s just pick one and try it. Maybe the relationship is \({diameter}^{something?} = {circumference}\)

For this circle, that “something” was \(1.50\). Does that work for other circles? Have we discovered a law of the mathematical universe? We can change the diameter and see the circumference change.

Hmm, nope. The circumference changed with the diameter but the new circumference didn’t line up. There is an easier way to see how wrong our guess it. We can show other circles with different diameters and see that our guess overshoots the circumference on the big circles and undershoots the diameter on small circles.

Making mistakes is okay. Let’s try anotehr simple relationship. Maybe (just maybe), it is \({diameter} * {something?} = {circumference}\).

For those of you in the know, the \(3.14\) is pretty promising. Let’s try it on other circle sizes.

What do you know?! It works on those other circles too! Maybe this relationship is universal? How weird that it depends on such a specific number like \(3.14\)… I wonder if that number ever comes up in other places? 😉

What is more fun than a circle? How about a square!?! 😮 This next puzzle is leading up to a pretty great one, so it is worth it.

With this square we can control the side length:

And we want to figure out the area of the square. For this one, we can tell it is \(81\) because everything lines up and turns a nice color.

We’ve got to find a relationship that ties those numbers together, but works for all squares. An enterprising (but, as we know, wrong) student might think the relationship is \(length * something = area\). Let’s see how that plays out.

Hrmmm. The area starts out too big on the small squares and doesn’t grow fast enough for the big squares. Let’s try a relationship that grows faster. EXPONENTIATION!

Sweet! It works for all the squares we care to test. We’ve discovered another law of the universe! 🏆

That set’s us up for the best puzzle I’ve programmed so far……

THE PYTHAGOREAM THEOREM!!!!! 😲

In this puzzle we can change the length of the blue line or the green line, and we are trying to figure out how big the orange line should be. We want that orange square to be all dark colored.

This puzzle could probably use some stars and sparkles when you get the right answer. 🤔 Open source contribution, anyone?

For this puzzle, randomly guessing relationships won’t be very successful. First, let’s do a part that we know. Those blue, green, and orange squares?

From the last puzzle we know how to make a square’s area. Let’s do that for each one.

Maybe this is progress, but what is the relationship between those squared numbers? For this part we’ll need a clever breakthrough, which we can get by studying the shapes.

There are two large squares of the same size. Each of those large squares has 4 triangles in it. Each triangle is the same size because they each have a blue, green, and orange side.

So, if we take away the four triangles, what is left? On one side we have the blue and green squares. One the other side we have the orange square.

The blue and green square must be the same size as the orange! We try adding them together…..

And voila! We’ve figured out the relationship between green, blue, and orange (or \(a\), \(b\), and \(c\), if you prefer). We can change the green number and our newfound relationship, \(a^2 + b^2 = c^2\) finds the new orange number.

We can even change the orange number and solve for the new blue number.

These puzzles show just the beginning of what could be done in Numberpad. Imagine trying to do these same puzzles with pencil and paper worksheets. In the words of Donald Trump, it would be a disaster.

The machanics of algebra on paper make it difficult to discover something new. It is more likely that a student would make an error like \({(a + b = c)}^2\). Worse, that student wouldn’t even know that was a mistake until the worksheet came back graded a few days later.

In Numberpad, a student has the freedom to play with math knowing they won’t accidentally “break the rules”.

If you think NumberPad could be used in a classroom, please reach out. I’d love to turn these prototypes into a curriculum. Email me at bridger.maxwell@gmail.com or find me on Twitter as @bridgermax.

Numbers can represent almost anything — saliva production per day, the cost of a pool on the moon, or the volume of earth’s viruses. Yet, on their own they are kinda boring.

NumberPad is for playing with numbers. (Check out this previous post to see the basics of NumberPad.) How can we show numbers in a less boring way? Here is one small experiment of tying those numbers to “toys”.

This football is tied to x and y. When those numbers change, the football moves to match.

We can make x and y both depend on time, then make the football move both directions at once. I set up the equations \(x = velocity_x * time\) and \(y = time^{power}\). With time selected, I can change the value and have it update both x and y.

If we wanted to tweak power and see how it changes the arc we could:

1. Select power.
2. Change it from \(y = time^2\) to \(y = time^{2.5}\)
3. Select time
4. Scrub back and forth to see the new effect

The turnaround makes it hard to see the effects of playing with a number. A better way is to see the entire trajectory of the football all at once, so we can instantly see the impact of a change. Here is a visualization of the football trajectory as I change power.

What you are seeing are “ghost” versions of the football at time + 1, time + 2, time + 3, etc as well as time - 1, time - 2, time - 3, etc.

The strength of NumberPad is that you can change any value without solving to isolate the variable. In this example, that means we can grab the football and have it change velocity_x and power automatically. As I drag the football and change x and y, NumberPad calculates \(velocity_x = \frac{x}{time}\) and \(power = log_{time}y\).

NumberPad tries to make equations concrete by always showing one solution to the equation because most equations are easier with one solid example. Sometimes a single example is not enough. The most important aspect of an equation might be how it changes. Showing the trajectory of the football is higher up the ladder of abstraction. From this vantage point we can see how our equation is about motion. We can also see how the motion itself changes with different values.

We can also use this abstraction to jump to different concrete solutions. Tap on one of the ghost footballs to jump to a specific time. Here I tap to jump to the concrete solutions where time is 2, 5, 6, 7, 9, or 11.

Putting this all together, we can play with the equation for projectile motion with gravity. We don’t have to change x, but the equation for y is now \(time * velocity_y + time^2 * gravity\). It looks more complicated in NumberPad because it shows step of the calculation.

Once the equation is set up, I can select time and scrub it to see the football fly through the air.

It is fun to play around with. I can grab the football have gravity change until we have the perfect arc.

Or, we change only the \(velocity_x\) and see that the ghost football stays in the air for the same amount of time. We can tell because it is always the same ghost football, which represents the football at \(time = 8.7\) which is touching the ground.

Toying with numbers is a fun way to discover relationships and get a feel for equations. Tying the numbers to a physical representation lets us visualize them in a concrete way, and the “ghost” effect lets us see the relationships at a higher level of abstraction.

I’m still at the stage where I’m prototyping these concepts in NumberPad. If you’ve got ideas for practical applications I’d love to hear them @bridgermax.

Read Part 3: Discovering Laws of Math

A few years ago, when I was reading Journey Through Genius, I encountered equations from Euclid’s Elements written as sentences.

Any cone is a third part of the cylinder which has the same base with it and equal height.

Today, we would write that relationship as \(volume_{cone} = \frac{1}{3} volume_{cylinder} = \frac{1}{3} \pi r^2 h\), but that notation wasn’t invented yet! That notation wasn’t even a notion. I hadn’t considered how math was done before algebraic notation was invented. It seems like \(2 + 2 = 4\) has always existed.

Algebraic notation is much easier to write than the notation Euclid used. We have some algorithms for manipulating the equations line by line (for example, performing the same operation to both sides of an equation in order to simplify it). This means human errors are less common, well, at least in mathematics.

Today, computers perform these rote algebra algorithms more quickly than we can. It is way easier than streaming and decoding cat videos, which is their primary purpose. We don’t have to worry about them making careless mistakes, either (user error notwithstanding). What if we invented a new notation that took the speed and accuracy of computers for granted? NumberPad is an exploration of a new notation that is built for the strengths of an iPad rather than pencil and paper.

Taxi fares

Let’s jump straight into a demo by calculating some taxi fares. Let’s assume that a taxi charges a rate of $3 per mile and an initial fare of $2. This is \(rate * miles + initialFare = total\). How much would it cost to travel 5 miles?

First, let’s multiply the $3 rate by 5 miles. The green square is a multiplier block. The two inputs will always multiply to equal the output.

This comes out to $15. We add that to the initial fare of $2 to get the total. The blue circle is the adder block. The two inputs, 15 and 2, always add up to equal the output, 17. A future update may contain the complex calculus and differential equation packages necessary to calculate adjustments for smell of the cab and the bad radio station choice factor.

We can add names to the variables to remember what they are.

So far, this is just a handwriting-based calculator. Pretty cool, but MyScript Calculator already does this with algebraic notation. What is the advantage here?

First, we can easily try different values and see how the changes flow through the equation. What if we traveled 7 miles? We can tap on miles and change the value to 7. The total value updates automatically.

We can tell which values will change by looking at the dotted lines between the values and the blocks.

Or, what if the per-mile rate was $3.40? We tap on $/mile to select it, then drag the number at the bottom to change its value.

The real advantage of NumberPad is that we can change “outputs” and see the effect on the “inputs”. For example, how many miles can I travel for $30 total? We tap on total to select it, then drag to $30 to change its value.

Again, when we drag the number, the values with the dotted lines are the ones that change.

By tapping on the lines, we can make different lines dotted or solid to control which amounts stay constant or react to changes. For example, we can also ask “what was the surge rate if I was charged $40 for 10 miles?” by selecting total and then tapping the light green line that connects to rate so that it is dotted.

Below each value, we can see the algebraic equations that NumberPad used to solve these equations:

However, these equations emphasize the different operators. It isn’t obvious that they are expressing the same relationship as the first equation (\(rate * miles + initialFare = total\)).

Relationships and exponents

Another example will help show the difference between operations and relationships. Let’s try \(2^5 = 32\).

The orange circle is the exponentiator block. It has a base of 2, a power of 5, and a total of 32.

Let’s ask “2 raised to the what equals 16?” While total is selected, we tap on the dark red line to “dot” it; this causes power to become the dependent variable (this also “fixes” base at 2, as shown by the solid orange line). Then, we set total at 16. We see NumberPad calculated the answer as \(\log_2 16 = 4\).

I remember logarithms being difficult to learn. They were scary! Like hearing someone use the bathroom at your house at night, and you live alone scary. Like using the LA interstate when your car is on “E” scary! Like telling your friends, you thought “Avatar” was just “ok” scary! Exponents were easier, but at the time I didn’t realize they were the same relationship. Logarithms are just reverse exponents in the same way that division is reverse multiplication. NumberPad makes this relationship clear.

We can also change the dependent / “output” variable to base and ask, “What other numbers work out nicely with \(x^4 = y\)?” We just tap the line connected to base to make it the dependent variable.

This equation was \(\sqrt[4]{81} = 3\). Another operator for the same relationship!

The way that algebraic notation is used in schools leads students to believe that the = symbol is a prompt for an answer. It is confusing in algebra to see an equation like \(4 + x = 8y\) which already has an “answer” after the = sign. It is a big jump to learn that the = symbol actually represents a relationship. The notation in NumberPad tries to make the relationship obvious.

Continuously compounded interest

We will do one more example that is a little more involved. The equation for continuously compounded interest is \(principal * e^{rate*years} = total\). Ideally we would be able to write that directly, but in this prototype let’s write it one piece at a time.

First, a rate of 3% multiplied by 5 years.

Then we take e and raise it to that result. We can drag from that result to the dark red node (which is the “power” of the exponentiator) to link it up.

Now we take our principal investment, $1000 and multiply it by the output from the exponentiator, 1.16.

At 3% interest for 5 years, $1,000 will yield $1,162. Ta da!

What if there were a higher interest rate?

We can also answer a more complicated question like, “how many years would it take to reach $2,000?” We just select total, tap the line connected to years to make years the dependent variable, and then set total to $2,000.

Once we write out the equation that sets out the relationship between values, answering these questions is easy and there is little chance of mistakes.

Why?

Math is a creative and powerful subject. If you find the right relationship between things, you can predict or control them! You will be the master of the math magic and turn the lame into toads! Even without a practical application, finding a truth or noticing a pattern in mathematics can be beautiful. As with any creative endeavor, you often have to play with ideas to make them work.

So why is math seen as repetitive and boring? I believe a big reason is that we spend so much time teaching the algorithms to isolate variables. There are tons of rules to memorize and if you break one of those rules (like adding to only one side of an equation, or distributing incorrectly) you don’t find out until days later when you’ve lost points on your homework or an exam. Computers are great at rote algorithms, so let them do the boring part!

There is a great essay, A Mathematician’s Lament by Paul Lockhart, which imagines a music class analogous to today’s math education:

“Music class is where we take out our staff paper, our teacher puts some notes on the board, and we copy them or transpose them into a different key. We have to make sure to get the clefs and key signatures right, and our teacher is very picky about making sure we fill in our quarter-notes completely. One time we had a chromatic scale problem and I did it right, but the teacher gave me no credit because I had the stems pointing the wrong way.”

In this world, students don’t get to hear music or strum an instrument until advanced college classes! I’d like to make an instrument for students to play with math and see its beauty without years of drills beforehand.

There are other experiments in NumberPad, which I’ll explore in future posts. NumberPad is an open source Swift project, so you can download it and try it on your iPad. It is only a prototype though, so it may have trouble with your handwriting or the solver may fail to see a solution.

Let me know @bridgermax if you enjoyed this essay or have any ideas for NumberPad. You can also open a GitHub issue.

Read Part 2: Playing with Numbers

Read Part 3: Discovering Laws of Math

The simplest way we can build on Auto Layout is a thin syntactic layer for creating constraints that we still manage manually. Until iOS 9, the built-in way to create a constraint was quite verbose. For example, to make the height of two views equal:

NSLayoutConstraint(item: redView, attribute: .Height,
                   relatedBy: .Equal,
                   toItem: blueView, attribute: .Height,
                   multiplier: 0, constant: 0)

The new Layout Anchor API makes this much easier to read:

redView.heightAnchor.constraintEqualToAnchor(blueView.heightAnchor)

Other layout libraries do similar things. I am a fan of PureLayout. These methods help you create a constraint or two, but wouldn’t be called layout systems on their own.

Higher up the abstraction scale is the Visual Format Language. When I interned at Apple on the Cocoa Frameworks team I helped with the initial implementation of Auto Layout and especially on the parser for the VFL. This lets you specify a few common layouts that can be written as ascii art.

I’ve experimented by reimplementing some of it in Swift using operator overloading. The idea is the same, but has the advantage of compile-time checking. By glancing at the code you should be able to see the layout.

view.addConstraints(horizontalConstraints(
  |-5-[redView]-0-[greenView]-0-[blueView]-5-|
))

When using the Visual Format Language you aren’t as concerned with each constraint, but the array of constraints is still passed back to you to manage yourself. It would be difficult to find one of those constraints and edit it later.

Even more interesting are libraries that are higher on the ladder of abstraction. UIStackView, also new in iOS 9, is a great example of this. Internally it uses Auto Layout, but you can get pretty far without ever managing a constraint yourself. Rather than constraints, you are dealing directly with ideas of alignment and spacing. I’ve got a similar layout library, StackLayout, which I’d like to talk about more.

Most layouts in practice are some variation on laying out views side-by-side vertically or horizontally in a container. Here is an example from Paper:

Described in english, this is 4 views arranged vertically. The container fits the contents except for some margins on the sides. There is consistent spacing except between the title and body. This is how it is written with StackLayout:

let verticalLayout = tipView.addSubviewsWithVerticalLayout(
    [titleLabel, bodyLabel, tipsButton, laterButton]
) { layout in
    layout.verticalAlignment = .Fill
    layout.horizontalMargins = 25
    layout.topMargin = 34
    layout.bottomMargin = 17
    layout.spacing = 21
    layout.setSpacing(5, between: titleLabel, and: bodyLabel)
}

Not only does this create all of the constraints for you, it returns a layout object which keeps track of those constraints and lets you modify them later. For example, the horizontal margins can be increased.

verticalLayout.horizontalMargins = 55

This is pretty similar to other layout systems, such as CSS’s flexbox. The fact that it is built on Auto Layout gives you some great advantages. It is a leaky abstraction in the best way.

Sizing children

Before Auto Layout, there was only one way to ask a subview what size it prefers to be, sizeThatFits(size: CGSize). Container views had to reimplement this method and do the math to combine all children sizes appropriately. This was often a duplication of the layout logic. Now, only “leaf” controls need to implement the Auto Layout intrinsicContentSize and the same constraints that govern layout also bubble up sizing information with contentFittingSize.

The old sizeThatFits method also couldn’t express subtleties, like the fact that a slider can be any width greater than ~40 but there is exactly one correct height. Or the way that a button can get smaller than its icon / label if it absolutely needs to (contentCompressionResistancePriority), or that it can get wider than its perfect size but it would rather not (contentHuggingPriority).

Sizing children views is no small task and it is a huge advantage that each layout system built on Auto Layout can take it for granted.

Exceptions to the rule / priorities

Layout systems usually have a few general rules that take care of most cases. StackLayout is a single row or column with spacing, alignment, and margins. It is a great system that will do absolutely everything you need, unless you are building interfaces meant for humans. Those inevitably have 1000’s of exceptions to the rules.

The exceptions are what make layout so tricky. If a layout system needed to accommodate every edge case the API and complexity would get out of hand. Instead of each layout system handling every exception, Auto Layout gives a convenient way to manually override some detail.

For example, in this login dialog the email field is below the Paper logo, except when it is not:

What vertical alignment should I use there? In StackLayout I can have it be top-aligned with a low priority, and then use a higher-priority constraint to move the email field below the logo. Additionally, I’ll need to override the width of the buttons to be equal widths.

loginView.layoutMargins = UIEdgeInsets(top: 30.0,  left: 20.0,
                                    bottom: 20.0, right: 20.0)

loginView.addSubviewsWithVerticalLayout(
    [logoView]
) { layout in
    layout.layoutMarginsRelativeArrangement = true
    layout.verticalAlignment = .Top
    layout.horizontalAlignment = .Center
}

loginView.addSubviewsWithVerticalLayout(
    [emailField, orLabel, googleButton, facebookButton]
) { layout in
    layout.layoutMarginsRelativeArrangement = true
    layout.horizontalAlignment = .Center
    // Top-aligned but with a low priority to be overriden
    layout.verticalAlignment = .Top
    layout.marginsPriority = UILayoutPriorityDefaultLow
    layout.spacing = 10
}

let logoToEmail = emailField.bottomAnchor
    .constraintEqualToAnchor(logoView.bottomAnchor, constant: 30)
logoToEmail.active = true // Deactivate to let the controls float to the top

// Other exceptions to the layout
orLabel.heightAnchor.constraintEqualToConstant(50).active = true
googleButton.widthAnchor
    .constraintEqualToAnchor(facebookButton.widthAnchor).active = true
googleButton.widthAnchor.constraintEqualToConstant(185)

Cross-layout constraints

Auto Layout lets views position relative to each other even if they don’t share a layout manager or if they have have different superviews.

The login dialog earlier has a Continue and Cancel button which should line up with existing buttons during the animation. There is also a loading indicator that might show where the Continue button is.

I can use the earlier layout without changing it and add the three new controls. There are ways to hack this in other layout systems using wrapper views, but Auto Layout makes it pretty natural.

// Align Continue with Google
continueButton.centerXAnchor.constraintEqualToAnchor(
    googleButton.centerXAnchor).active = true
continueButton.centerYAnchor.constraintEqualToAnchor(
    googleButton.centerYAnchor).active = true

// Align Cancel with Facebook
cancelButton.centerXAnchor.constraintEqualToAnchor(
    facebookButton.centerXAnchor).active = true
cancelButton.centerYAnchor.constraintEqualToAnchor(
    facebookButton.centerYAnchor).active = true

// Align loading indicator with Continue
loadingIndicator.centerXAnchor.constraintEqualToAnchor(
    continueButton.centerXAnchor).active = true
loadingIndicator.centerYAnchor.constraintEqualToAnchor(
    continueButton.centerYAnchor).active = true

// Later, use alpha to fade the buttons in and out

Pixel Integralization

“Pixel-integralization” is making sure that frames of components fall on pixel boundaries, rather than a blurry line in between two pixels. This is trickier than it sounds — if you just round all of the frames you won’t get the best results. Auto Layout has the global knowledge needed to make everything fall on pixel boundaries even on the iPhone 6+ where each point is 2.6 pixels.

RTL languages

Another tricky issue is support for RTL languages. When you read right-to-left, it makes sense to switch the entire interface so labels are on the right and actions are on the left. If you use the Leading and Trailing attributes on Auto Layout this is done automatically for you.

If you’ve liked these examples, give StackLayout a try. It is available on CocoaPods, where I hope to see more layout systems built on the Auto Layout engine too.

While a photograph has 4 dimensions (x, y, intensity, color), a light field of the same scene has 6 dimensions (x, y, Θ1, Θ2, instensity, color). That is a lot of information! Optics Workbench works with 2 dimensonal scenes, which are easier to manage. A “photograph” in this 2D environment has 3 dimensions (x, intensity, color), and a light field has 4 dimensions (x, Θ, intensity, color). Mapping Θ to the y-axis, and this can be visualized in a graph.

You can try this out for yourself in Optic Workbench. The sensor is the component with a white side and a black side. The white strip captures light rays. Clicking on the sensor shows the light field graph. Notice how the graph is transformed when you move or rotate the sensor. You can apply these transformations digitally after the light field is captured. For example, digitally moving the sensor to refocus the image. This is what the Lytro has done.

I spent a lot of time making sure it was easy to manipulate the tools on the workbench. Drag a new one from the library in the bottom left. You can move it by dragging near the center of the tool. You can rotate it by dragging on the purple circle. You can resize by stretching the tool. You can modify the focal length of a lens or parabolic mirror by a simple drag.

The simulation is very straightforward. It works like this:

• First, each tool on the board has a chance to emit “starting rays”. These are added to a list of active rays. Each ray has a starting position (x,y), an angle, and a color.
• Now the simulation enters a loop. One of the active rays is chosen and removed from the list. The distance to each tool is computed, and the closest intersecting tool is chosen. A line is drawn from the origin to the intersection point.
• The tool that the ray hits then has a chance to “transform” the ray, and return an array of new rays. For example, a mirror will return a new ray starting on the mirror, and with the reflected angle. A beam splitter returns two rays. One is reflected, and one continues on the same path. Each is half the intensity of the original ray. These transformed rays are added to the list of active rays, and the loop continues until all active rays are gone.
• The application requires OS X Lion (10.7) to run.

Get a copy of the source code on GitHub

Download the application