This document provides an overview of the summer projects I have available for Grinnell students and the expectations I have of my summer students.
This page may be found online at
The application guidelines can be found online at
In summer 2006, I began a new area of research. In particular, I began to study of the application of the Scheme programming language (and, more generally, the functional programming paradigm) to a variety of image-based computations. I call this general project ScheMedia. This summer, I hope to continue this area of research. My emphasis has shifted a bit - I am now making it a priority to contribute to or initiate Open Source projects relevant to this work.
A different team will work on each subproject. Between two and three students will be on each team.
The Open-Source graphics editor called The GIMP includes a variant of Scheme, called Script-Fu, as a scripting language. Unfortunately, all of the published work on Script-Fu focuses on the imperative aspects of Scheme - it's filled with begin blocks and set! commands. It seems that Scheme was used primarily because it is a small language with little syntax, and not because it is a functional language. Script-Fu also lacks some key procedures that are likely to be useful to novices (such as uniform treatment of colors).
I am convinced that a careful, functional, approach to Script-Fu will reveal some significant powers. For example, it is likely that image transformations can be expressed in terms of a map-like function.
In Summer 2006, my students and I began to explore this issue. We built a library to better support higher-order programming, tried a variety of experiments to compare the paradigms, and began to measure relative efficiencies. The students have presented their results at a department seminar, at the Grinnell Science Poster Session, and at the Pew Midstates Science and Mathematics Consortium's Undergraduate Research Symposium. We also have a much better sense of what metrics we should use to compare different approaches.
This summer, I hope to have students improve the library for reliability and, more importantly, for efficiency. In particular, students are likely to reimplement some of the key routines in C, a lower-level programming language. Once those key library routines have been implemented, we will further explore the comparative efficiency of the imperative and functional approaches.
Students working on this subproject will code in both C and Scheme. Students will need thorough understanding of higher-order programming (that is, writing functions that take functions as parameters or return functions as results), but may do so through focused study in the early weeks of the project or beforehand. This subproject will also benefit from students with experience in Photoshop or the GIMP.
About ten years ago, some researchers at Dartmouth College developed
a version of Scheme that permitted computation with time-based media,
particularly with video. They called that project VideoScheme.
VideoScheme was clearly a powerful approach. A section of Peter Gloor's
Elements of Hypermedia Design suggests some basic applications.
That section is available on the Web at
Unfortunately, as in the case of Script-Fu, Scheme was used primarily as a small language, and not as a functional language. (Examples are filled with calls to set! and loops.) Even more unfortunately, development of VideoScheme was abandoned about eight years ago.
Last summer, a group of three students VideoScheme, starting from scratch. The new project, which they dubbed Phoenix, was quite successful. In less then ten weeks, they had a nicely working system (albeit one with bugs).
This summer, students will add new features to Phoenix, including more support for sound, for the analysis of individual frames, and for compositing video. As importantly, from my perspective, they will put it into a form that we will be comfortable releasing it as an Open Source project, one available for others to use, most likely at SourceForge.net.
Students applying for this subproject should be familiar with the Java programming language and with Scheme.
In the past year, the Open Source community has seen the release of a very different kind of graphics program (at least as compared to the GIMP): Inkscape is a vector graphics program. While the focus of the GIMP is pixels, specks of color on a screen, Inkscape emphasizes higher-level drawing components, such as lines and shapes. (While the GIMP supports drawing such things, once they are drawn, they are rendered as pixels, so the original information that they were once lines or circles is lost. In Inkscape, that information is retained.) Surprisingly, Inkscape lacks an interactive scripting environment, similar to the GIMP's ScriptFu. At the SIGGRAPH conference, I spoke with some of the architects of Inkscape, and they expressed interest in having me (and my students) work to develop that scripting environment. This is an exciting opportunity for me, and one I expect the students will find equally exciting.
I expect that most of the development this summer will be in C++. Knowing SVG would also be helpful, but not necessary.
Note that any usable software we write is likely to be distributed under some form of open source model.
Much of this schedule mimics the schedule officially approved by the division. Note that I will certainly understand if students accept a position with me and then later choose to take a position elsewhere. In that case, I will notify students on my waiting list. The ten weeks of summer research are currently under discussion. The schedule may move up or back a week.
I have very high expectations of my summer research students. Among other
things, I expect my students to begin their
summer research during
spring semester and continue their
summer research into fall
semester (and sometimes beyond). By applying for summer research you
are agreeing to meet these expectations if I take you on as a research
student. You are unlikely to receive explicit credit or compensation
for work in the spring and fall.
As some students from the past may have reported, I expect my students to be self-reliant. While I do my best to be around, I expect you to be able to do many things on your own or with a small group.
During the summer, you are expected to work full-time on the project (40-50 hours per week for ten weeks). This work will include scheduled daily group meetings.
the state of the artin whatever project you've decided to undertake. You should prepare a short survey paper. On the first day of the second week, you will give a public presentation of your work.
There are, unfortunately, a number of conflicting issues I must consider
as I choose who to accept for summer research. While one goal is
certainly to enhance my research, summer research also helps students,
the department, and the institution. My approximate priorities are as
follows, although I will certainly take some students from
categories before taking every student from a
Because women and domestic students of color are under-represented in computer science, I will strive for some equity in the mix of students I select. I hope this will encourage more members of these groups at Grinnell to participate in computer science and, as they go on to successful careers, that they will further encourage others. I have begun to imitate the early research experience program in Physics and will reserve a few slots for first-year women and students of color who have expressed an interest in and aptitude for computer science. It is likely that these will be the only first-year students I take for paid positions.
Applicants should fill out the divisional summer research application,
which is available at
http://www.grinnell.edu/academic/gensci/summer2004/includes/Sci%20Div%20Summer%20Res%20App.doc. In addition, applicants must prepare responses to
the Glimmer application form, available at
Finally, students must meet with me for a fifteen minute interview.
I am likely to distribute the essays (project description for upper-division students, essay questions for first-year students) from your applications anonymously to a group of trusted advisors. We will each evaluate each person's essay or essays on a 1-4 scale.
After evaluating the various parts of the application, I will score each applicant using something like the sum of the following:
I may discuss applicants with colleagues before and after the interview. While the interview and those discussions are not directly incorporated in the score, they provide additional information. In particular, I will not necessarily use the rankings as an absolute order. For example, a very poor interview may disqualify you, no matter how good your overall score is, and I may bump up a person with an excellent interview or who past experience suggests will fit well in my research team. I may also prioritize students with certain skill sets.