91.204.202 Computing IV, Spring 2014
Prof. Fred Martin,
⚠ (:html:)<a href="http://mailhide.recaptcha.net/d?k=01COSqrfJ-58cc94fQb2pI1A==&c=iZBP8kCznrjdnfw8QFFKADFtsIimnLdVHk581djoISQ=" onclick="window.open('http://mailhide.recaptcha.net/d?k=01COSqrfJ-58cc94fQb2pI1A==&c=iZBP8kCznrjdnfw8QFFKADFtsIimnLdVHk581djoISQ=', '', 'toolbar=0,scrollbars=0,location=0,statusbar=0, menubar=0,resizable=0,width=500,height=300'); return false;" title="Reveal this e-mail address">click for fred's email</a>(:htmlend:)
TA: Bhanu Khausik, firstname.lastname@example.org
Mon/Wed/Fri, 10a 10:50a, OS402
Materials for this course will provided on this site and in links to other sites. We will not use a textbook.
As of Spring 2014, the catalog listing for 91.204 Computing IV says:
This is old, and we'll be shortly revising it to something more like:
But even this doesn't tell the whole story, because various faculty who have taught / are teaching the course do very different things:
- Prof. Xinwen Fu teaches principles of computer vision and practical applications using OpenCV
- Prof. Jesse Heines teaches XML parsing and language processing
- (former UML) Prof. Li Xu taught a 6-week module on compiler design
- Prof. Bill Moloney used to teach how to build a calculator using Lex and Yacc (i.e., parsing and grammars)
- Prof. Emeritus Bob Lechner says the course used to be about building a linker (personal conversation)
Probably the only thing that can strongly be claimed about the course throughout the years is do stuff in C++, have the students write lots of code, and do cool stuff. (Of course, this last one depends on one's definition of cool.)
I'd also say that there definitely existed a point in time when having all students learn how to write a linker was absolutely the correct answer.
Now in Spring 2014 though, the course is an oddball in that it's required, but it's allowed to vary a lot based on instructor interests.
So, what will be doing in my class this semester?
- We will definitely be writing lots of code
- We will be doing it in C++
- We will be using some pretty cool APIs, including SFML, a free, open-source simple fast media library for C++, which is available for Mac, Win, and Linux (translation: it's a gaming library)
- Best of all, we'll be working through some awesome problem sets developed over the last 15 years at Princeton by Robert Sedgewick.
The Princeton stuff is great because it's all about how computing connects to the larger world.
It's not the usual stuff about using computing to do ever-more complicated things. This is necessary and valuable, but it's kind of self-referential and insular. Dare I say, incenstuous.
Here are some of things we'll be doing:
- Using Newton's laws of planetary motion and the leapfrog finite difference approximation method (don't worry; it's easy) to create a totally realistic simulation of our solar systemcomplete with live animation
- Comparing sequence strings based on their on their edit distancea technique widely used in bioinformatics for DNA analysis
- Using a linear feedback shift register to cryptographically encode and decode an image
- Simulating the vibration of a guitar string, with a thing called the Karplus-Strong algorithm (also not too bad). This will include generating actual audio files and listening to them
Also in a partnership with Kronos, a Chelmsford, MA-based company which happens to be the largest employer of software developers that has its headquarters in MA:
- Parsing 0.5 MB error logs generated by malfunctioning InTouch devices, their hardware time-clock unit. Note: these are not neatly well-formed like proper XML!
Based on the historical role of the course in UMass Lowell's computer science curriculum, and my hopes/plans for the semester, I shall predict the following learning outcomes:
- You will become much more comfortable writing C++ code and using object-oriented methods.
- You will gain experience architecting solutions to reasonably well-structured problems.
- You will learn how to use some great C++ APIs (not only SFML, but Boostby the way, we're going to be doing some unit testing stuff).
- You'll gain practice with the most important thing about documentation, which is: Naming. Stuff. Well.
Collectively, these things represent to me what is the most important learning outcome of the course, which is you progressing down your journey of becoming an effective and confident software engineer.
Also, I won't be teaching you to use an IDE. You are welcome to use your favorite one, but I won't be requiring their use nor teaching them.
I do hope you all share your favorite development environments with each other.
When I do stuff with you in class, you'll be seeing Emacs, the Unix shell, and Makefiles.
Also #2, you're welcome to use your favorite platform (as long as it is one of Linux, Mac OS X, or Windows).
- I'll be using Linux. If you don't have a strong preference you should choose that.
- I can provide you with some help for Mac, as long as you're not using Xcode.
- If you're on Windows, that's fine, but you'll need to turn to your classmates for support.
OK, that's the course overview! Now on to some more tactical things.
Course Structure and Grading
The class will have regular weekly assignments, which will be graded and returned.
Cumulatively these assignments are worth 50% of your overall grade.
Assignments will be accepted up to 1 week late with a 50% reduction in that assignment's value. If you fall behind on your homework, it is much better to cut your losses and work on the current assignment, instead of running behind trying to catch up.
There will be two in-class exams during the semester. Each is worth 10% of your overall grade.
There will be a cumulative final, worth 20% of your overall grade.
Classroom participation is worth 10% of your overall grade. In practice, if your other grades put you on a marking boundary, this will push it one way or the other.
50% Weekly homeworks
20% Two exams
10% Classroom participation
Discussion Group / E-Mail List
We will use Google Groups for class conversation and announcements. Please join this group.
There are two ways to sign up:
- (better) Log in to your Google account, go to https://groups.google.com/forum/#!forum/91-204-202-s14, and request to join, or
- (easy but then no web access) Enter your preferred email in the box below.
<table style="border:1px solid #aa0033; font-size:small" align=center>
<img src="http://www.cs.uml.edu/ecg/uploads/OPLspr14/googlegroups_logo.gif" height=58 width=150 alt="Google Groups">
<td colspan=2 align=center><b>Subscribe to 91-204-202-s14</b></td>
<td>Email: <input type=text name=email></td>
style="background-color:#ffcc33;padding:2px;border:2px outset #ffcc33;">
<input type=submit name="sub" value="Request">
<tr><td colspan=2 align=center>
<a href="http://groups.google.com/group/91-204-202-s14" target="new">Browse Archives</a>
If you do the Google web method, I'd advise setting your preferences to immediate, individual delivery of messagesclick the Edit my membership tab.
If you do the email method, and you provide an address that's not linked to your Google account, I'll choose those delivery options for you, and then if you don't like it you'll have to ask me to change it, and we'll both be annoyed, so don't do that.
In either case you can send email to the list with mailto:email@example.com.
If you sign up on the web, you can browse conversations at the group link (see top of this page).
Lecture blog and lecture capture
I will strive to maintain a daily blog of highlights of what happened in class each class meeting. These notes will be recorded in the Lecture Blog page.
In-class activity will be recorded using the University's Echo360 lecture capture system. This material is intended for your use if you must miss class, or if you want to go over again something that was presented/discussed in class.
A link to the Echo360 recordings is at the top of the Lecture Blog page.
Echo360 makes a high quality recording of the classroom's data projector and the instructor's voice.
It also produces a low-resolution recording of the front of the room (i.e., me walking around writing stuff on the white board), and a low-volume capture of student remarks (depending how close to the microphone you're sitting, and how loud you are).
If you arrive at class after 10a, and walk across the front of the room, you'll be captured by the low-res overview cam.
If you're a talker and you're at a decent volume and near a mic, people will be able to hear you on the recording. (They won't see you sitting in your chairmaybe the back of your head if you're at the front of the room.)
If it bothers you that your voice will be captured, and you want to feel comfortable speaking up, please let our TA know and the TA will anonymously refer your concerns to me. We'll set up the captures in a more private way.
Individual work. Most assignments must be completed individually. You are welcome to discuss ideas in the class with your peers. You may not look at each others' code, nor allow others to look at your code. If you need to post code on our own course forum for help, or a public forum, do not post more than three lines.
When turning in an individual assignment, you attest that, beyond any starter code I have provided or has been provided in standard API and reference documentation, you are the sole author the code that it includes.
Pair programming. A few specific assignments may allow pair programming. There will be highly structured rules for these (which are intended to make sure both partners have a substantial learning experience).
This will be discussed later in class, and this document will be updated at that time.
Academic integrity. Please be familiar with the university's policy on academic integrity.