Category Archives: engineering

Computer Science & History


Artificial Intelligence (AI) isn't a new phenomenon. For that matter much of what we value in the way of formalism in Computer Science, isn't new either since computers were analog (and human) before they were digital. Abstract concepts such as memory, state, event, iteration, and branching are ubiquitous in the real world. One exploring these concepts should not have to stare at a computer screen to learn them.  The concepts are larger in scope than found in digital technologies. Jessica Riskin wrote a nice historical piece entitled Frolicsome Engines on the history of AI through mechanical automata, . In Computer Science (CS) we tend to be historically, if not culturally, illiterate. There are many issues at play here, with the main issue being that within Engineering, there are few electives since the goal is to educate students for specific skill sets. Maybe topics such as philosophy and history are tangential to CS? The core skill sets, theoretical or practical, stem from early mathematical research in the 1930s. Before the 1930s, I suppose we tend to think of the history of computing as non-existent. Do other areas in science or the liberal arts such as mathematics, physics, and chemistry suffer the same fate of removing history from their curricula? Do math teachers not talk of history when covering geometry, algebra, and calculus? I don't have a good answer to that, but I do need to start digging for answers.

Formalized Synesthesia


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].

Personalized Model Learning

Property release:3 Model release:Q,E,J


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.


It's About Time


A long time ago, I told a friend that I was starting to move more deeply into the field of modeling and simulation. The friend said to me "It's about time." How true. For no particular reason other than it being January 1st, I thought it appropriate to celebrate the 555 timer integrated circuit (IC), which was designed in 1971 by Hans Camenzind. This is one heavily-used IC, and it can be purchased well under one US dollar depending on the source. The above picture is called a block diagram -- which is a high level design description of how the IC functions. If you looked inside, you'd find mostly transistors with resistors and a couple of diodes. Think of the 555 as something that can create a well-timed oscillating square wave, or just a "one shot" pulse of a given width. An egg timer, but more precise. Having just sung the praises of this IC, we also need to put this technology into context with regard to time management. The most accurate time is kept by atomic clocks, such as those employing cesium. In the semiconductor world, there is also a tug of war, sort of, between MEMS-based oscillators (oscillators built into the silicon) and quartz (which you may have seen on an Arduino or other similar micro controller). All of these technologies are "about time." With the Internet of Things (IoT), computers built around micro controller chips are getting much smaller, more powerful, and are cheaper (although not yet at the < $1 level). For example, you can make your own bare bones Arduino for about $4. You can program a 555's behavior in software rather than through voltage dividers and a capacitor. What will 2015 bring us? There is no time like the present.

Big Process


Big Data: it is (still) all the rage. And rightfully so because we have access to more data than ever before. The "bigness" of data refers mainly to the sheer magnitude or volume of data available for our consumption. This volume has increased exponentially and shows no sign of abatement. But data indicates one side of the coin. Process is the flip side. Without process, the data repository is a large pile of undifferentiated pieces. Even a "data structure" is a process in disguise since the structure reflects a procedure that must read and write to this structure--thus creating it. This idea of process, in a miniature scale, can be seen in programming. Once upon a time, the program and the data occupied the same memory space, and to the unaided eye, the computation looked like a collection of hexadecimal bytes -- which ones were the data and which were the operations? Who knew? A careful deciphering and knowledge of the opcodes showed us the way. Today, the idea of "process" is essential if one has lots of data. How are the data sensed, processed, merged, diverted, massaged, and transformed? Like a petrochemical plant, the raw materials (e.g., data) are useless without a clearly engineered, and formally represented, process flow. Big data needs big process and big model.

Abstraction and Sushi

Abstraction is part of what makes us human. We are able to reason about things by forming abstractions. I enjoy eating sushi, but what is sushi except as a conceptual category of raw fish with rice?  I feel a need to understand sushi, the concept, by eating different kinds of sushi or by reading about sushi in an article, or by looking at many pictures. By doing so, my understanding of the sushi abstraction is made clearer. So, abstraction is not all in the mind; I need to physically experience many examples of sushi to strengthen the mental concept....the abstraction. We can approach abstraction in mathematics and computing in the same way. By seeing many examples of "plus", I come to understand what "plus" means. The above video was a short lecture I gave on the topic of abstraction to students and parents visiting the University of Texas at Dallas (UTD) during Engineering Week. If abstraction is made strong through experience, new possibilities emerge. A "plus" is made real around us, while also giving us increased understanding of this concept.

Making the Abstract Concrete


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.

Models of Addition



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).

Engineering Week


Our Creative Automata Lab had its open house during the Engineering Week celebrations on Saturday, February 22nd (yesterday between 10am and 2pm CST in Dallas). The turnout was phenomenal. I have to thank the organizers of the week-long event and to all of my students who created amazing demonstrations for everyone. What are the summary points? People like to touch things, play with them, and understand fairly complex mathematical and computing phenomena by experiencing them firsthand; hearing, seeing, and interacting. Writing on the whiteboard doesn't cut it any more. The two 3D printers (Maker Bots) in the lab were exciting for visitors not so much because 3d printing is a new phenomenon, but because these printers have visible moving parts. You can see what is happening because the printers  are designed to show their internal components, a bit like the Centre Georges Pompidou in Paris. We'll be sorting out lessons-learned from the event for some time to come. Next up will be blog posts on our exhibits and the video that was compiled based on student thoughts and the lab mission.


Castle Clock Teaching



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.

Lighting the Computational Future



Computational Thinking. Everyone must code. The most recent Communications of the ACM (CACM, Feb. 2014) has an article where the author covers the issues of learning computing. Should everyone code? Not everyone needs to code as we soon find out, but we do recognize that writing a computer program does help us think in terms of algorithms, mathematical structures for a new generation. We can use one of the excellent programming languages employed for teaching how to code such as Scratch or Java.  Does this provide insight into computer science? Yes, it is a direction that most of us take in the field when instructing students. But here is another suggestion: Everyone must model. Consider the Bunsen burner.  The chemistry lab is for learning how to use lab instruments, and Bunsen burners are valuable instruments since they rapidly heat the contents inside of Erlenmeyer flasks. Computers are equipment, just like Bunsen burners. Look closely at the Bunsen burner in the illustration: what information is there and what is it doing? A modeler looks at the burner and sees two streams of information merging. And an imaginary discrete event: lighting a three inputs. One of the streams is modulated (e.g., the air control) using a range delimited by a minimum and maximum mechanical setting. This should be the essence of computational thinking: learning how to model information, not writing code inside of a text editor.

Alive and Kicking



Da Vinci's cam hammer was covered briefly here. This object was the "object of the day" during the Creative Automata class at UT Dallas (Jan 22, 2014). At the start of each class, students are shown an object from real life in a photograph or perhaps from an illustration. In this case, the object is a picture of a kit model that I made and later stained. The physical model was handed out during class for handling and observation. The driving question is "What information do you see?" This question elicited a wide number of expected and completely unexpected responses, all of which were welcome since this exploration is how we communicate and learn about computing. The first comment was that there was a conditional branch on the snail cam. You can see the cam driving the follower (the rigid linkage that connects to the hammer on the right side). When the follower makes contact with this discontinuity in the cam, the rising hammer falls, causing a change in state (another type of information flow---of control). Someone said that there was a stack (a type of data structure similar to a stack of plates), but when we went looking for the stack, it was not clear that one existed. The support structures for the cam shaft are inverted ternary trees of height one. Seeing information--in an ancient machine. However, the technology goes much further back than Da Vinci in what were called trip hammers written about by the Chinese in 40BC in the Ji Jiu Pian dictionary. So, foundations for computing were were alive and kicking early on with hammers.