http:^^www.cs.hmc.edu^~keller^cs60s96.html

This data set contains WWW-pages collected from computer science departments of various universities

Although much of the course entails programming, we  consider exposure
to computer science ideas to be the important part.  The intent of the
programming assignments is to drive home these key ideas.  I am
willing to devote as much of each class period as is needed (nominally
15 minutes) to more detailed examples of programming techniques and
for specific programming questions and answers.  If this does not
appear useful on a given day, the time will be used for other
purposes.   

<p>
<b><h4><a name = "honor_code">Honor Code Standard</a></h4></b>

<em>Read this carefully:</em>
Although <em>discussion</em> of problems with others is encouraged,
programming in CS60 emphasizes individual learning rather than group
projects.  We observe the following Standard:  "You may <em>discuss</em> the
assignment with other students.  You may not
share (= give or receive)
written work of any kind, inside or outside the course".
Elaboration:  In the case of programming assignments, we consider
email, computer files, fragments of files, and printed output to be "written
work".  In developing code for a programming assignment, you can
discuss ideas with others, but discussion of ideas
must not involve wholesale examination or 
transcription of the actual working code of
others, with the exception that you may use any code explicitly
provided by the instructor. <strong>Definitely
forbidden</strong> is a form of collaboration wherein two or more students
split up an assignment, then transcribe each others' contributions,
sometimes changing names of variables, comments, formatting, etc.  
If this occurs, a failing grade is issued automatically.
If the help you get from another is significant, you should acknowledge
it on your submission.  You do not lose credit for this.
<em>If you have any doubts about whether a form of
interaction constitutes a violation of this standard, please consult
with me prior to continuing.</em>
<P>

<b><h4><a name = "grading_weights">Grading Weights</a></h4></b>
The programming assignments will constitute 50% of the grade.  The
mid-term examination will count 15% and the final 25%.  Class
attendance, participation, random quizzes, etc. will account for the
remaining 10%.  Various "practice problems" will be indicated.  In
particular, you should be able to work most ** ("two dot") problem in
the notes relating to material covered in lecture.  These do not need
to be submitted, but the exams will consist largely of problems of a
similar level, along with some perhaps a little easier or harder.
Exams are open book and emphasize conceptual understanding, rather
than memorization of fine details.  
<P>
<b><h4><a name = "late">Late Assignment Policy</a></h4></b>

Submissions are done by emailing source code to the grader,
cs60grad@muddcs, which also establishes the time of submission.
The due dates on assignments should be noted carefully.
The work of an assignment should be conducted in the week or weeks
before, not on the last day when there is no space for the necessary
thinking.  
There is an automatic, fixed, one-day grace period on all assignments.  
In other words, if the due date
states day N, then the assignment must be turned in before midnight on
day N+1 to receive any credit.  After midnight on day N+1 work you
spend on the problem is for you own edification only (which is not 
to say that it isn't worth doing or required; you just don't get
points for it then).  It is best to plan to get the assignments in
on the stated due date.
<P>
<b><h4><a name = "outline">CS 60 Topic Outline</a></h4></b>

The lectures will roughly follow this outline.  The progression is at
the rate of about two of the numbered topics below per week.  I should
say that this is what I would <em>like</em> to do.  Depending on background,
some of the topics expand to longer than allocated, with the result
that other topics get jettisoned or fall off the end.  Please keep up
on the reading without it being explicitly assigned.  The notes
generally expand on the lectures and discussions.  But the lectures
may also expand on the notes or introduce new material.  More often
than not, several threads will be interwoven in the lectures over a
period of time, in part to emphasize the commonality of concepts from
different vantage points.  Brackets below indicate where chapters in
the notes start with respect to the concepts that follow.  The outline
does not mention every topic.  The actual lectures determine points of
emphasis.
<P>
<ol>
<li>[<em>Computing by the Rules</em>]  Computation problems and models of
computation. States and transitions.  List notation.   Functional
specifications.  Computation by rewriting.
<p>

<li>Heterogeneous lists and trees.  Mutual recursion.  Anonymous
functions.     
<p>

<li>Assignment-based programs.  McCarthy's transformation.  Turing
machines.
<P>

<li>[<em>Computing on Demand</em>]  C++ review, the Polya library
(translating rex to C++)
<p>

<li>
RAM model, linear addressing principle,
arrays, pointers, L-values and R-values.
<P>

<li>[<em>Computing Grammatically</em>]  Inductive definitions, grammars,
syntax.
<P>

<li>Parsing.   Evaluation.  S expressions.
<P>

<li>[<em>Structural Computing</em>] Data structuring.  Dynamic storage
allocation.  Open- vs. Closed-list models
<P>

<li>[<em>Computing Objectively</em>]  Object-orientation and data abstraction.
C++ objects.  Inheritance.
<P>

<li>[<em>Computing Logically</em>]  Proposition logic and applications.  Gate
realizations.  Minterm expansion.  Boole/Shannon expansion.
<P>

<li>Logic simplification.  Hypercubes. Karnaugh maps.  "Don't care"
situations. 
<P>

<li>Predicate logic.   Programming in logic.  Backtracking. 
<P>

<li>Program specification, correctness, and verification.
<P>

<li><a name = "midterm">Mid-term examination</a>.  (<b>Date of Midterm: Wed. Mar. 6, during class period</b>).
<P>

<li>[<em>Complexity of computing</em>]  Runtime measures. Profiling.
Growth-rate comparisons.  Upper bounds.  "O" notation.   Examples from
sorting: Heapsort, merge sort, radix sort.
<P>

<li>Complexity (continued).  Empirical measurements.  Set abstraction examples.  Bit-vectors,
tries.
<P>

<li>[<em>Computing graphically</em>]  Directed graphs.  Graph representations,
depth- and breadth-first search.
<P>

<li>Weighted graphs.  Shortest paths.  Traveling salesman problem.
<P>

<li>[<em>Finite-State Computing</em>]  Finite-state machines.  Sequential
logic design.
<P>

<li>Regular expressions and finite-state machines.
<P>

<li>Computer components.  Registers, buses, multiplexors, etc.
<P>

<li>[<em>Computing with the Store</em>]  Stored-program computer structure.  
<P>

<li>Assembly language.
<P>

<li>[<em>Computing physically</em>]  Physical bases for computation.
<P>

<li>[<em>Computing in Parallel</em>]  Parallel computation.
<P>

<li>[<em>Limitations of Computing</em>] Finite-state limitations.  Lower
bounds.  Incomputability.  Intractability and NP-completeness.   The
glitch phenomenon.
<P>
<li><a name = "final">Comprehensive final exam</a> (<b>Date of Final: Fri. May 10, 2-5 p.m.</b>).
</ol>

<b><h4><a name = "mailing_assignments">How to email assignments:</a></h4></b>
<b>Use the following scheme only:</b>
<listing>
    elm -saN [e-mail] < your-code
</listing>

where N is the assignment number and your-code is a file containing your
code.  <b>Do not, under any circumstances, mail
using PINE.  This MIME encodes the file and we can't use it easily.  </b>
</html>