This is the start of my life in programming. 10th Grade. Downingtown High School in Pennsylvania. My father told me of an after-school class being taught by two teachers from a local college-- West Chester State College as it was known at the time (1970). In my first class, I was provided with a blue/green IBM plastic programming template. I think the first assignment was to write a program that read a count (N) of numbers, averaged these numbers, and then output the average of the numbers. We had a card punch machine in the school, and our card decks were shipped to the College for processing. Later, we received our green-striped paper output. It was a long process. Although some may see programming as a sort of automation, I was creating a new "machine" with each program. Imagine being told that you could create a machine, but that you'd need to "write" a machine rather than build one. This is the essence of programming. Even today, a program is a mental model of an ethereal machine--stuff that moves around, is stored, and manipulated. Writing doesn't really do the "machine" justice. It is really all visual, a mental model, and I used writing because that is all that was available. Today, coders and modelers do the same thing -- they create imaginary machines that are not quite real--all existing in the head, but real enough to reason about unless too many weeks have passed, and the formerly crisp memory of the machine begins to decay. The goal of programming and modeling is not to automate a task but to understand one. What better way of understanding something than to design a machine to recreate that thing? Want to know how to bake an apple pie? Write a program. Create an apple pie machine. As the old saying goes, if you cannot write a program (or make a machine) then you don't understand the task sufficiently.
I recently engaged in a three-way podcast conversation covering research that we do in the CA lab, as well as activities in the Creative Automata class that I teach--if that is even the right word. Guide? The title of this post is gleaned from Christopher White who works with Elecia White. I engaged in dialogue with both of them, and thoroughly enjoyed our discussion. Elecia and Chris produce a podcast called Embedded where the main theme is embedded systems and electronics. But they tackle a wide variety of interesting topics around this central theme. This audio podcast name Bubblesort Yourself was invented by Elecia, and the hour long podcast can be found here. Their Embedded podcast can also be accessed using the Apple podcast app or the equivalent app on Android phones and tablets. I listen to their podcasts regularly, and also to other podcasts while I take long walks. For some of you, driving the car or working out in the gym may be good times for podcast listening. Chris White also posted an accompanying blog entry where he expands upon formalized synesthesia. Is that what we do when we model in simulation? It seems to be on the basis that we employ many models, each of which contains a hidden set of analogies. The models are encoded with respect to our senses [credit: artwork Synesthesia above is from Nuno de Matox].
Much of what we do in the Creative Automata (CA) Lab is oriented around multiple representations of a single abstract mathematical concept--such as integration in calculus or sorting in computer science. How can we personalize approaches for learning something like integration? Is it possible to leverage our multiple cultures to engage and motivate the learner? The lab just submitted our video entry to the National Academy of Engineering (NAE) Grand Challenges for Engineering Video Contest called E4U2. Sharon Hewitt from the CA Lab designed and produced this video. The video segments include representations of a virtual analog computer based on the sand-like flow in PowderToy, as well as several personalized models of the Lotka Volterra model. Instead of making models for other people, consider that you can learn about modeling by making these wonders for yourself. In this arts-based approach, you will also interest other people in modeling.
When I teach modeling and simulation, I tend to focus mostly on the structure of models. I start with a thorough discussion of time and systems concepts, and then move on to cover different sorts of dynamic models in both discrete and continuous space. In the past, I had relied on using examples purely from the real world in emphasizing the importance of modeling. For example, all fast food restaurants, manufacturing lines, and theme parks have one thing in common: queuing networks. A queuing network is a dynamic model abstraction of what happens in these things: objects (often people) wait in line, get served, and move on. In teaching queuing, and other, models, I am trying something new this Fall. I am starting with human-interaction and media being the means by which to get students interested in modeling. For example, the single server queue (SSQ) shown above has an operation that can be both seen and heard. This one is programmed in Max/Msp (which is a visual language with strong roots in music, imagery, and video). The SSQ is experienced, by tying events to an audio synthesizer. Everything is in software. An SSQ becomes an audiovisual instrument.
During Engineering Week at the end of February, the Creative Automata Lab hosted an onslaught of visitors of all ages. We showed several projects representing the Lotka-Volterra predator-prey relationship, a mechanical integrator using simulated sand, and the use of force feedback in embodied interactions with the distributive law of algebra. A video was produced from the projects, and students are interviewed for their perspectives. The video can be seen by using this link or by clicking on the photo of the ATEC Building shown above.
Isn't addition like this: 1 + 2 = 3 ? If your technology is a typewriter, it is. This is certainly true for this blog since my human-machine interface is quite limited. And that is an interesting aspect of modeling: all models are tied to the technologies used to design and create them. So, if you have a marble quarry, then all of your models will look like stone. And if you use a typewriter or, equivalently, the modern keyboard, then your models will look like Arial, Helvetica, Times Roman, or whatever font family you happen to employ. For Szücs (Similitude and Modeling, 1980), the above mechanical components are models of addition. It is a way of thinking about mathematics using the technologies required to make gears and pulleys. There is nothing magical about typography in mathematics--it is just cheap and therefore useful for communication and standardization. Something that is not immediately apparent, but important, is that the models of addition contain the parameter of time. The addition using standard notation for simple addition is S(t) = a(t) + b(t).
For my Fall 2013 simulation class, I decided to try something a bit different than the usual verbal onslaught of modeling methodology with mathematics and scattered applications. We used a type of learning that is most commonly known as object-based learning, and frequently practiced in museums such as the one in University College London (UCL). An object is chosen as the focal point of collaborative discovery. So, we chose al Jazari's 13th century water clock which goes by "Castle Clock" because of its original physical location. Al Jazari was one of history's great masters of mechanical invention. The clock is an astronomical computer, like all time pieces. This turned out to be a fun and useful learning experiment but it had its challenges as well. The issue is that the academy (which is to say most places of formal learning) is splintered into multiple disciplines. So, while the students in the class had a roller coaster ride through history, culture, systems dynamics, computer science, physics, language, and mathematics, this approach runs counter to how we normally teach students, and how students and faculty get credit for their work. My gut feeling is that as the academy evolves, this mode of learning will become more common and the credit and disciplinary issues will evolve with it. At UTD, we are making inroads here and things look quite positive.
Our lab's first model products will be a set of prototypes of the Lotka-Volterra (LV) model of predator-prey competition. If lions (predators) chase gazelles (prey), then there are mathematical relationships that can be expressed to capture the overall population change resulting from this effect. The LV model was proposed in 1910 according to the Wikipedia article as a "theory of autocatalytic chemical reactions," and then extended in 1920 for organic systems. In the model, we find the fairly general terms present that make the dynamics interesting--growth (birth), decay (death), and interaction effects modeled as a multiplicative effect of the population variables. You'll find these same terms in many other mathematical models. Returning to the lab, we chose this model out of thin air based on some sketches I made on the office whiteboard seen above. Unfortunately, there are some errors in the design, but it was some sort of beginning. Despite the confusing juxtaposition of figures, we observe a transition from equation to block model, and then to an analog model based on water flow. The idea for the spherical floats at the surface of the water will be familiar to all those who have had to correct leaky toilets containing older ball-cock supply valves. The redesigns and creative prototypes of LV will be unleashed in future issues of the blog over the next month.
What is a complex system? The word "system" is less controversial and clearer to most since a system is composed of elements such as states, events, transforms (and other functions), input, and output. However, "complexity" is...complicated! In casual conversation, if we say that a system is complex then it is seems hard to understand. When you think of complexity, consider two spaces: the problem space where you formulate a model, and the solution space, which reflects simulation--where you execute that model on a computer. The fractal behavior in the Mandelbrot Set seems complex but that is only in solution space. The equation where this set is defined is very short and simple and not complex at all (well, it is formulated in the complex plane, sigh, but that is another meaning of complex). In contrast to the equation that spawns the Mandelbrot Set, we find the vast world of software. Talk about complex. Yet, the complexity lies in the problem space (defining the algorithms and writing the computer programs). There are many definitions of complexity, including Halstead's definition for software (a function of the number of operands and operators in the software). Complexity can be interesting and curious for science, and to be avoided in other cases as when we seek to engineer safe, quality products.