Several people have noted that I have printed very few— less than a dozen— of the literally thousands of pictures I have taken in my more than four years of owning a digital camera. I wanted to rectify that problem in a unique way with something other than a stack of four by six prints. I wanted posters. Three of them, one for each of the folders in which I have kept pictures from 2002, 2003, and 2004. I made the 2002 poster tonight. It contains pictures from the latter half of my senior year of high school and my first semester here at Purdue.
The full-resolution picture is 16 by 30 inches at 300 DPI. I plan to print it on the vinyl I use for my drawing posters.
If I have known you for that long, chances are you are on it somewhere. Extra credit if you can name more than ten events.
I started reading deeply in my first source for the history paper this evening. I briefly mentioned (second to last paragraph) that I was considering moving away from the history of machine tools as a topic. I am glad I did not return the books on that feeling because it has turned out to be surprisingly interesting. These early industrial pioneers were able to create, with their own hands and almost from scratch, powerful and precise means of shaping material. The enginuity needed to devise these machines was quite impressive. By 1776, could "[bore] a 72-inch cylinder being not further from absolute truth than the thickness of a thin sixpence in the worst part." The book captures the essence of this innovative thinking, and is much less dry than I had feared.
It also has a lot of cool pictures. The last half of one of my other sources is filled with several hundred schematics, patent illustrations, and photographs of modern reconstructions of industrial tools. House-size engines, borers the size of a person, water-powered lathes, grinders, drills— all sorts of interesting machines. Very .
I made heavy use of my highlighter for the Kepler paper because I owned my main source. I cannot do that with library books, so I bought about 200 sticky tabs with which to mark important lines. Two chapters in, and the book already looks like it is supporting a jagged, neon pink fungus.
A book a week, then another week of writing, and this paper could be almost doable.
It is Monday, the day I had to have all four of the items on the top list completed. I did it, and with minimal pain. I even finished the OS projects early, giving me a Friday away from the computer. Numerical analysis took two evenings. The parser ate up my entire Sunday except for a few hours before bed during which I made a few Industrial Roundtable logos. The following is a sampling of the eight I packaged for the committee to choose from:
I hope they like one of them enough to adopt it for next year's job fair.
In previous semesters I would get a short rest after cresting a wave of work such as this one. Not this semester. The todo list on my planner has grown despite completing those four assignments. My goal is to have everything done by Friday in time for spring break. Then I get my rest.
Update
Eric tells me they decided to go with someone else's design. Oh well.
I take back what I said about getting a bit of a rest from work. I came out of the woods only to find myself knee-deep in a sticky swamp of new assignments. Aside from the last of the 15 goals and a large bug to fix on the OS project, I now have at four other large assignments on my plate:
The next OS project. It is due at the same time as the revised due date for the current project. Fortunately, I hear it will take at most two hours to complete. We have to build a simple threaded program. Easy.
Numerical analysis problems. These assignments take entirely too long for the number of questions. Last time, two questions took me three days. I joked with that it was almost as bad as his normal ChemE assignments.
A parser for the research project. , , and I are all in the same OS class, so The Big Shell Project has monopolized most of our time. We have designed a language syntax with the help of our advisor, but I am ashamed to say we have not had a chance to code anything until now. I am writing the parser that will create our internal object structure. Ahhh... memories...
logos. Eric is a member of the which runs the Industrial Roundtable job fair. My new Buy Stuff page prompted him to recommend my design services to the IR committee. I have to provide them with a portfolio of options by Monday. If they choose my design, I will get a small fee and my creation on all the literature for the event. That would be quite cool. Would that make me a professional graphic designer?
All this in addition to at least a half dozen personal projects, each of which deserves a post of its own:
My class notebooks have yielded a handful of drawings that I want to retrace, color, and post. At the top of the pile is a sheriff to accompany the gunslinger.
I hope to unveil an addition to this weblog after spring break. Failing that, before summer break. It combines my affinity for introspective statistics and data visualizations with a desire to play with Javascript's magical object. XMLHttpRequest allows one to create . I have big plans for this project.
I have not forgotten that I promised to add categories to my posts. This and many other incremental code changes will one day come to pass.
There are at least three books that I am currently in the process of reading. One, William Hope Hodgson's , happens to be . I have two others on my shelf, and many, many more perpetually on my . I recently got a library card for the West Lafayette Library, so my shelf will probably grow while my wishlist slowly diminishes.
I have kept a growing list of future weblog post subjects in my Palm. I hope to start working through that list, too.
I still have not used my birthday present. I have picked a company with my father's help. I still need to sign up with one of the many online brokers in order to buy the actual shares in it. Dad has also spoken with a financial advisor and family friend with whom I plan to roll some old savings bonds into mutual funds. All that will surely have to wait until spring break.
I have always believed that one should do things rather than complain about the things one has to do. However, I am doing quite a bit at once, so I think I am entitled to a little bit of complaining. I wish that first list would go away, giving me time for the second.
I took some time last week to research prior art relating to the undergraduate research project. A few minutes of searches on (which I love O so much) led me to several papers that appeared promising. I was dismayed but not surprised to find a handful of very smart people had already explored many of the ideas , , and I had brainstormed. In a way it is reassuring that our ideas were useful and practical enough to warrant study.
The first paper almost exactly echoes the basic idea of a programmatic vector language. Van Wyk's language, called IDEAL, is certainly far more elegant than three undergrads could have devised in a semester.
A programming language that includes special constructs for drawing pictures is discussed. The
language has been designed so that programs to draw pictures can reflect the structure of those
pictures.
...
A variety of graphics languages is available. Some are simply standard notations
for basic graphical operations like point placement and line and circle drawing. Others include operations like translation, rotation, and scaling, which
can be applied to sets of primitive objects. All of these systems rely heavily
on the use of explicitly computed coordinates. They also lack a procedure
mechanism, that is, there is no way to group several graphical operations together
and refer to the whole by a single name.
Another approach to graphics languages has been to allow access to graphics
commands from a high-level language such as FORTRAN...
This second article defines both a constraint-based (i.e. programmatic) graphics language as well as a WYSIWYG editor that one can and use. I wish Adobe Illustrator had some of this type of functionality.
Juno is a system that harmoniously integrates
a language for describing pictures with a
what-you-see-is-what-you-get image editor. Two of Juno's
novelties are that geometric constraints are used to
specify locations, and that the text of a Juno program
is modified in response to the interactive editing of the
displayed image that the program produces.
...
Several years ago I used METAFONT and Draw to
produce figures for my thesis....
The contrasting virtues of these two programs inspired
me to design Juno, a system that integrates a programming
language like METAFONT with a WYSIWYG image editor
like Draw.
Chris had the idea to design our language as a based on . We had not gotten beyond just the idea, but Finne and Jones did in the context of , another functional language.
We present in this paper a simple, device-independent model for describing two-dimensional graphics using a functional
language. Graphical scenes, or pictures, are represented as values that functions can manipulate and inspect
to create new values. Complete pictures are constructed by repeatedly composing such picture values together using
picture combinators. A novel aspect of the model presented is its use of structured translation to abstractly express
the geometric composition of arbitrary pictures.
The structured graphics model presented has been implemented in Haskell, and we also give an overview of a
general rendering framework for traversing a picture value. Applications of this renderer include both output to various
graphical systems, testing for picking or selection of a picture and the computation of the bounding box of an arbitrary
picture. The graphics model forms the basis for all graphical output in a user interface framework being developed in
Haskell.
My teammates, Professor J., and I met on Monday to discuss these papers and what direction we wanted to pursue in light of the ideas they contained. Did we want to extend the work already done or did we want to brainstorm some more and try to come up with something completely different?
We chose the former. We still plan to work on a programmatic graphics language, but that will not be the focus of the project. Instead, we will use our language to explore some of the aspects involved in "compiling" such a language. We see our compiler having several possible forms of output: a simple raster image, a normal vector language, a programmatic vector language such as those detailed in the papers, or even a general-purpose language utilizing a graphics library. Other programmatic graphics languages can only output a simple raster or vector image that discards any of the logic or constraints present in the original language. What if our "compiler" retained as much of that as it could? It would be interesting to, say, design a picture programmatically, then output a .gif, a Postscript diagram, and even Java code that one could stick in an interactive applet.
A programmatic graphics language compiler with multiple output formats seems like an ideal computer science research project. It lends itself well to questions like: "What kind of programmatic functionality does it make sense to have the output contain?" "How does one convert one form of programmatic flow to another, possibly completely different, form?" "What possible optimizations can one make to a picture based on the target format?" "What problems does a graphical focus present?"
I am excited to see where the project goes from here.
I have some news on the undergraduate research situation that I briefly mentioned at the beginning of the semester. However before I get to that, let me expand on the bullet point in the linked post. (I apologize for the length. As usual, this one aspect of my life expanded to epic proportions.)
I want to go on to graduate school after I complete my four years here at Purdue. I am 99% sure that will result in a master's degree, but I am still split 50-50 on whether to continue to a PhD from there. The 1% in the former case is reserved for some amazing job offer that would warrant postponing grad school. The latter case is far more complex and worthy of a post unto itself. Luckily I still have a year and a half to think about it.
In preparation for whatever I decide, my counselor advised me to do undergraduate research. Grad schools appreciate research experience when considering admissions, and it is good to start as early as possible. I did not start looking for a research sponsor early enough last semester and projects consumed all my time once I did. Despite that I had two tenuous leads.
The first professor specialized in GUIs and GUI optimization. and I spoke to him about one of his projects involving program auralization. Think "visualization" but with MIDI. By running source code through the application and compiling the output, the resulting program would play "music" when it executed. Somewhat nifty. It goes along with programmers' love of bizarre data representations. However the application was almost finished and had few uses beyond a toy or hard-to-use addition to a debugger. Our research would involve "finding its killer app". We could expect minimal programming; certainly nothing involving MIDI or language parsing, the two parts of the project that interested Lee and me.
I decided not to pursue that research opportunity. Was I being picky? Perhaps, but if I am going to work on a semester-long independent study project, I want it to be with something I enjoy and that would look good to recruiters. I didn't feel that a nearly complete "music box" satisfied either criterion.
I learned about the second professor— let's call him Professor J.— through a classmate named . Professor J. specialized in programming languages and was interested in discussing some of the ideas Chris and I had brought up in last semester's "preparation for undergraduate research" seminar course. It seemed like a good fit except that he was out of the country. I had not heard from him by the end of the semester, so I feared I would have to postpone my undergrad research for next year.
Professor J. responded just as the new semester began (here we arrive at the bullet point). He, Chris, and I quickly scheduled a meeting to brainstorm on research options. We touched on visual programming languages, typography, program visualization, and functional languages, among other things. We didn't reach a conclusive project idea, but it gave Chris and me a place to start thinking.
Chris and I planned to get together a few days later to bang out a project idea. I proposed that we include Lee in the meeting and project group. After all, I worked with him in our compilers course and had planned to do research with him and the first professor. Chris was open to the idea, so the three of us met.
The following is a snippet of the email I sent to Professor J. explaining the project idea we came up with at that meeting.
[snip]
Chris and I have made progress on starting the undergraduate research we spoke to you about last week. We met on Friday to brainstorm ideas based on the topics we discussed in your office. I invited a fellow CS honors student named Lee Ballard to join us. We had a productive three-way discussion and now feel we have a good basic idea for a semester project. Can we meet with you sometime this week to get your input and direction as well as discuss the possibility of Lee joining the group? Chris and I both feel that a three-person team would yield a very impressive project.
The idea we came up with drew from our talk about typesetting and visually augmented languages. We batted around ideas for visual debuggers, improved typesetting languages, and niche visual languages based on functional languages; all things brought up in last week's meeting. From typesetting and functional languages we progressed to more generalized vector languages such as Postscript, SVG, and others. It seems these languages lack-- and you will be able to help us verify this-- some kind of built-in programmatic functionality. For example, to plot some mathematical curve, a scientist must write a program or use a pre-made package that plots points and exports a final picture in the vector language. We asked ourselves, "Would it be possible to make a vector language that includes this functionality natively? That is, could a vector image language contain control flow and functional structure similar to a multipurpose language? If so, how would one design such a language, how would it function, and what would be a good use for it?" These questions are all good foci for research.
One can also look at this question from the point of view of a general-purpose language. Most languages with a graphical component tack it on as a secondary library. (i.e. Java's various Swing graphics classes) On the other hand, some vector languages allow for programmatic control via a programming language tacked on to the vector data. (i.e. SVG and Javascript) A programmatic vector language such as the one we were discussing would blend the drawing and control flow into a unified environment.
We feel this path (if it hasn't already been tread; again, you can help us determine that) offers a great deal of research promise. We look forward to discussing it or possible alternatives whenever you are available to meet.
[/snip]
The four of us met today to talk about where to go next. The meeting was terrible (I do not want to go into why), but we left with three goals for the near future:
Define the abstract scope of the project. We need to figure out what the program will do while avoiding the trap of defining exactly how the application will work. Questions about the languages, libraries, interfaces, and output need to wait.
Think about the basic questions. Why pursue this project? What problems will it solve? What needs will it satisfy? What can we or the world learn from it?
Figure out if it has already been done before and modify numbers one and two as necessary. This is the important one. It is disturbingly likely that someone has thought of something similar before. As undergraduates without research experience or research knowledge, we have no clue what work people have done already. We hope that our idea fits in a niche between graphics libraries and declarative vector languages. If not, we need to think harder or expand on what has already been done. "To Google!" is our mantra.
All three of us have built personal programs for our own enjoyment and class projects for the grade, but this will be our first big independent project in academia. I plan to record our progress throughout the semester. Unlike a job, I can write about a research project as much as I want.
