A Self-Directed Program
For A Bachelor of Computer Science Degree
Dan Brown, Mark Giesbrecht, Naomi Nishimura, J.P. Pretti, Geoff Pounder, Prabhakar Ragde
December 12, 2001
Summary
The self-directed approach to designing a degree starts with a modest core and permits more
choice in third and fourth year, with distribution requirements to ensure that students avoid
extremes. We have applied this philosophy to designing a B.CS, and propose a core with
reductions in both Mathematics and CS courses. The number of required Math courses is
reduced from 11 to 7, and the number of core CS courses is reduced from 11 to 9. The total
number of CS courses required for graduation remains the same. We also propose distribution
requirements on the non-Math and free-choice courses to ensure they are used wisely. The first
year of our B.CS program is the same as all other BMath programs. We also propose
modifications to the BMath(CS) program which increase both the number and seriousness of the
Math courses, and offer some observations on the possibility of a 3-year general CS program. All
of our decisions are explained at length, and alternatives are indicated where feasible.
Index
1. Introduction
1.1 Myth: It's all Math's fault
1.2 Myth: Changing the way we teach will threaten our reputation
1.3 Drawbacks of the comprehensive or "thick core" approach
1.4 Myth: With a self-directed approach, students get off easy
1.5 Myth: Allowing flexibility damages the value of the degree
1.6 The use of comparisons to model curricula or other programs
2. The self-directed program proposal
3. Rationales for details of B.CS proposal
3.1 Math content
3.2 Systems courses
3.3 Algorithms and data structures courses
3.4 Scientific computation courses
3.5 Distribution requirements
3.5.1 Requirements on specialization CS courses
3.5.2 Requirements on non-Math courses
3.6 Upper-year courses, options, and other programs
3.7 Justifications for other CS core courses
4. Renewing the BMath(CS)
5. Rationales for BMath(CS) changes
5.1 Math content
5.2 Mathematical CS content
5.3 Other details
6. A 3-year general program in CS
6.1 The current General Mathematics program
6.2 The general B.CS program
6.3 Notes on the general B.CS program
Appendix A: References
1. Introduction
The self-directed model for our programs offers flexibility to both students and faculty. It
permits individuals to create plans of study that can be broad, focussed, or interdisciplinary. It
does not squeeze all students into a "one size fits all" framework. At a time when many other
disciplines are introducing "computational" programs, it avoids a narrow, exclusionary definition
of computer science.
The B.CS program proposed here is not a radical change from our current practice. At a time of
strained resources and increased responsibilities, any additional change can be seen as excessive.
Nevertheless, we support a reorientation of our flagship undergraduate program, because a
modest effort now, in the context of the creation of a School of Computer Science, will pay off in
the long run. Our proposal would set in place a framework within which our curriculum can
evolve gracefully over the next ten to fifteen years.
1.1 Myth: It's all Math's fault
The B.CS initiative came out of a desire of CS to gain more autonomy over its affairs, and a
feeling that too much of the content of the B.Math(CS) was not under the control of CS. But
some of our injuries are also self-inflicted. Many of our problems cannot be wholly or even
largely blamed on Math intransigence or interference: student workload, burnout, frustration, and
attrition; overlap or gaps in coverage; curricular inflexibility and inertia; loss of control over the
content or delivery of CS courses. As we re-examine and re-engineer many of the ways in which
we operate, we should also take a close and critical look at all aspects of our curriculum. A selfdirected approach will not solve all of our problems magically. However, we believe that the
flexibility and diversity possible within this approach offer more scope to address our problems.
Getting our own house in order will demonstrate our fair-minded approach to reform.
1.2 Myth: Changing the way we teach will threaten our reputation
We constantly change the way we teach. In the last decade we have introduced two CS courses
in second year and more requirements in fourth year, moved from breadth-first introductory
courses to the CS1/CS2 model and then from imperative-based to object-based approaches in
those courses, changed teaching languages and platforms, moved away from digital design
towards architecture, and suffered the near-doubling of many class sizes. About the only constant
has been the philosophy of specifying courses through third year, which we inherited from a 48credit degree created under very different circumstances. Our current curriculum has not been in
place long enough to be responsible for a significant share of our reputation, yet its problems
threaten the future development of our image.
1.3 Drawbacks of the comprehensive or "thick core" approach
From a faculty member's point of view, requiring courses through third year makes adapability
difficult. Upper-year courses have a limited teaching pool under current policy; they are often
left in the hands of groups or individuals who may aim at enthusiasts rather than general
audiences -- one of the attitudes we complain about with respect to Math courses. It is harder to
ensure universal acceptance and respect for all core material if the core is too thick. Introducing
new material requires removing something; because the core covers a wide area, those who
"own" the removed material can find other material that is equally marginal and deserving of
removal. Those whose "owned" material is not in the core resent this.
A thick core increases the amount of material a student sees as irrelevant or overly timeconsuming. While this attitude can be overcome with careful motivation, that is not always
provided. Students have difficulty pursuing other interests (whether supplementing or
complementing their CS studies), getting a well-rounded education, or focussing their studies in
preparation for graduate school. It is difficult to design new interdisciplinary programs without
arguments over what part of the core to leave out. As computing becomes an integral part of
most other disciplines, computer science risks being marginalized unless it can demonstrate its
willingness to build bridges to these other areas.
Our current core, in certain areas, goes well beyond what is required for Ph.D exams in most
graduate computer science programs. It is natural to base qualifying requirements on
undergraduate core, but graduate students from diverse backgrounds who join our program are
put at an early disadvantage that is largely unnecessary and discourages interdisciplinary
approaches to research. The same discouragement holds at the undergraduate level. Evidence
suggests that women value applicability of CS concepts, and a self-directed program could
permit them the space to explore areas of application.
1.4 Myth: With a self-directed approach, students get off easy
This presumes both a desire on the part of students to shortchange themselves and the presence
of easy or trivial options. Both are present in our current program, but they are the result of the
comprehensive approach, not prevented by it. Both students and faculty members argue that
courses such as CS 494 -- which we have never had in-house expertise to teach, and on which
most students report spending zero to two hours a week outside of class -- should be retained as
compensation for the legendary demands of some other courses, including ones in the core.
Those demands are also responsible for a culture in which non-CS courses are given short shrift,
instead of being an integral part of a well-rounded education. Recognizing this, colleagues both
within the Math Faculty and in other faculties are moved to create undemanding courses,
knowing that our students will avoid ones with challenging content.
Attention to quality of individual offerings (which will be naturally focussed by not having a
captive audience for higher material) and distributional requirements to avoid extreme
imbalances in choices will avoid such problems. It is hard to find someone to argue that students
at Berkeley, CMU, and MIT (all self-directed programs with requirements similar to our
proposal) are getting off easy.
1.5 Myth: Allowing flexibility damages the value of the degree
The value of the degree primarily lies in the knowledge and skills acquired by the degree holder.
Under the thick core approach, graduates are more similar to each other, and those who have
experience with one UW CS graduate can more easily judge another. Leaving aside the question
of whether this type of transferred judgement is one we wish to encourage, the fact remains that
this consistency, to the extent it actually exists, has been ensured at the cost of discouraging or
barring those who wish to move beyond our relatively narrow parameters. Diversity is a source
of strength.
1.6 The use of comparisons to model curricula or other programs
Why should we design our curriculum a particular way just because some committee advocates
that approach, or because other institutions use it? The answer is that we should not, and this
proposal does not suggest blindly following any given external model. We have unique strengths
and circumstances at UW and can build on them. We have used model curricula and other
programs as "reality checks", preventing us from circular reasoning in which what we do is
valued simply because we do it. They allow us to test our decisions by comparison with the
academic world we inhabit.
Here we rely on two such checks. The first is the Steelman draft (following Strawman and
Ironman) of the ACM Computing Curricula 2001, a successor to the much-used Computing
Curricula 1991. The classification of core knowledge and description of sample curricula in this
report is the result of work by several teams of well-known and distinguished researchers and
educators. Each of us can find something in this report to criticize; it attempts to reflect a wide
range of practices, and to cover decade-old traditions as well as recent trends that might prove
pervasive in the future. The details may change in the final report. Still, it is a well-researched
document, and extreme divergence from its models deserves increased scrutiny. There is a link to
it on the B.CS Web page (see Appendix A for references). In this proposal, when we refer to a
course design in the Steelman report, we append the letter S to create the acronym SCS; this
allows us to distinguish Steelman courses from our CS courses.
The other comparison we make is to self-directed programs among the top 20 CS research
departments in the US (as ranked by a 1995 NRC report) and a number of top Canadian
departments. Since we are a research-intensive department in a university which prizes and
publicizes such activity, it is natural to use these programs as a basis for comparison, and to look
for good ideas that might transfer into our context. Details are generally available on institutional
Web pages, though members of both design teams have summarized the results on the B.CS
Web page for those who don't wish to hunt for them.
2. The self-directed program proposal
It is easiest to understand our proposals to create a new B.CS and modify the existing
BMath(CS) by comparison to current practice. We based our decisions on the benchmarking of
the current BMath(CS) against the core described in the Steelman report and the cores of selfdirected programs at other institutions. Central to our analysis are the practical issues of
interchangeability with other Math degrees and the inability to mandate a large amount of new
course development. Our aim is to have both programs remain viable, not to have a BMath(CS)
which will wither away due to lack of enrollment.
Below we describe the requirements for the current BMath(CS) and the proposed B.CS degree,
as structured by the checklists in the CS Undergraduate Handbook. Translation of these into
calendar format is straightforward. The description is followed by notes pointing to more
detailed discussions in Section 3 of particular suggested changes.
Current BMath(CS) degree
11 Math courses: Math 135, 136, 137, 138, 235, 239, Stat 230, 231, 3 others not in CS
11 CS core courses: CS 130, 134, 241, 251, 240, 246, 341, 342, 354, 360, 370
4 CS specialization courses: CS 4xx (three must be 440-489)
10 Non-Math courses
4 Free-Choice courses
New self-directed B.CS degree:
7 Math courses: Math 135, 136, 137, 138, 239, Stat 230, 231
9 CS core courses: CS 130, 134, 241, 251, 240, 246, 341, Logic and Computation, Sys 1 (see
notes below)
6 CS specialization courses: CS 3xx, 4xx, or 7xx (with distribution requirements to avoid
excessive concentration in subject or year)
10 Non-Math courses (with distribution requirements)
8 Free-Choice courses (above distribution requirements may affect these)
Notes:

Section 3.1 describes the modifications to core Math and Stats courses, as well as the new
Logic and Computation course.

Section 3.2 describes changes to systems courses. The new courses Sys 1 (core) and Sys
2 (specialization) replace CS 342 and CS 354.

Section 3.3 describes changes to algorithms and data structures courses. The advanced
algorithmic content of CS 341 will be moved to CS 466; basic computability moves from
CS 360 to CS 341, and CS 360 becomes a specialization course.

Section 3.4 discusses the reasons for making CS 370/371 a specialization course.

Section 3.5 discusses the details of our proposal for the distribution requirements for CS
courses and non-CS courses.

Section 3.6 discusses implications for other 3xx and 4xx courses, and for other programs
and options.

Section 3.7 briefly justifies the CS and Math core courses we have not addressed in the
other sections.
3. Rationales for details of B.CS proposal
In the following sections, we present detailed rationales for the changes proposed here. Note that,
modulo some changes in emphasis in various topics, a B.CS student could still make choices that
result in exactly the same program that they could take under the current BMath(CS) rules, with
the one addition of the required Logic and Computation course. They could also make choices
which would not be allowed under current BMath(CS) rules; the current BMath(CS) is more
restrictive.
3.1 Math content
In specifying the Math content of the B.CS degree, we were motivated by the desire to preserve
what is useful and desirable, and to enhance the value of this content both to faculty and to
students. The amount of supporting math content, as specified by the Steelman report or by a
perusal of topics in CS courses requiring math background, is relatively small. But the study of
mathematics has benefits beyond direct support of CS topics, and we cannot ignore the argument
that the reputation of Waterloo CS is based in part on the mathematical exposure of our students.
Our proposal reduces the non-supporting math content of the B.CS relative to the current
B.Math(CS). The three extra non-CS Math courses (otherwise unspecified) have been removed,
as well as the second linear algebra course. This latter course is taught in a fairly abstract
fashion, and while it may be valuable as general mental exercise, it results in a crowded second
year and reduces flexibility.
On the positive side, our proposal would result in all Math Faculty students taking the same
Math and CS courses in first year, allowing transferability between programs at least to the end
of first year (and probably later, with judicious choices). We have assumed that the changes in
1st year algebra and calculus proposed by the Ad-Hoc Committee to set up a program in
Computational Mathematics will be made. These changes make the first year courses more
accessible to CS students while improving the core for all students (at least from the point of
view of the non-CS people on the Ad Hoc committee).
We assume that Math 239 will be changed to make enumeration coverage more concrete and to
make graph theory coverage more algorithmic; this puts most of Math 239 within the Steelman
core. We also assume that a CS version of Stat 231 will be developed to focus specifically on CS
examples. The experimental nature of computer science is underemphasized in our current
program; one cannot seriously talk about the performance of a processor, a network, or a system
without bringing in statistical concepts. The current version of Stat 231 does not work for most
of our students, but we have faith that this can be overcome. Signs indicate that the Math Faculty
seems inclined to cooperate on all of the above changes.
A changed Math 239 will satisfy the discrete mathematics requirements described in the
Steelman report and common to many institutions. It does not address the need for coverage of
propositional and predicate logic and their applications. Students need not only exposure to
logic, but exercise in its use in a CS context, and we do not believe that a Math course, even one
specifically offered to CS students, will achieve this. A Math course in logic will be seen as part
of their Math requirements rather than part of their main course of study, especially if it
resembles PMath 330 or if logic is handled in a "grab bag" manner such as the list of topics in
CO 103 or the Steelman course SCS 115.
Instead, we propose a CS course in Logic and Computation, similar to the one to be offered by
the joint SE program for the first time in winter 2002. This course uses program verification
through assertions to motivate logical manipulations. It strengthens the ability of students to
reason about control flow in the design process, and emphasizes the possibilities and limitations
of formal methods, both pencil-and-paper and machine-assisted. The course seems ambitious as
designed for the SE program, but we believe a version of it will be suitable for B.CS students in
their 2B term.
3.2 Systems courses
It is difficult to suggest changes to CS 342 and CS 354. These two courses are central to our
current program, popular with students, and taught for the most part by excellent instructors.
They put students through a tempering process by which they gain a deep understanding of
important material. Why, then, are we suggesting revising them?
To put it briefly, they are too much of a good thing. If one were to try to design a program in
mathematics, one might be tempted to make the Sylow theorems on subgroups or Goedel's
incompleteness theorem required material; in a program in science, one might insist on quantum
mechanics or protein synthesis. These are all excellent topics, and learning them properly will do
any student good. But they are not core material. They are appropriate for certain mathematicians
or scientists and not appropriate for others. Similarly, the material in CS 342 and CS 354, taken
together, is appropriate for many (perhaps even most) CS majors, but not for all.
Our comparison of CS 342 and CS 354 to the Steelman core and to systems courses at other
institutions is on the B.CS Web page; the precise URL is given in Appendix A. Below we
summarize the result of our investigations.
The combination of CS 342 and CS 354 make the current CS core overweight in the systems
area. The main problem is with CS 342. By our estimate, 23 out of the 36 lecture hours in CS
342 are not in the Steelman core. In fact, in the Steelman report, some topics from CS 342 only
show up in the advanced course SCS 337 (Concurrency and Distributed Systems), designed
primarily for the systems-based approach. But that course is based around a distributed
networked approach, whereas 342 is based on shared memory. Other 342 topics do not appear at
all in Steelman.
CS 354, being an operating systems course, conforms more closely to the Steelman core. The
areas in which it exceeds core (in topics such as file systems and security) are not extreme
outliers. Its main problem is that CS 342 is a prerequisite. While some understanding of
concurrency is necessary for proper coverage of operating systems material, most institutions
devote six to eight hours to this background. CS 342 far exceeds the required amount.
Adding the concurrency material makes CS 354 overfull, but the new CS 251 relieves some of
the pressure: it contains initial discussions of pipelining, caches, virtual memory, I/O, and
multiprocessors, all of which will help. We believe this permits the design of a single course,
which we call Sys 1 here, covering most of 354 plus the core parts of 342 (six hours of
concurrency). This is in line with the practice at other institutions we surveyed (details on the
B.CS Web page).
The self-directed design team does not have the expertise to design a handbook description of
Sys 1; we suggest (as an example rather than a prescription) something along the lines of SCS
230 (Operating Systems), with some of the parts of SCS 221 (Architecture and Operating
Systems) included (alternately, 251 could incorporate some of that material). Note that the
lecture material in the current 354 is due for revision in the light of the new 251, and that 354
instructors are scheduled to update or replace the NachOS system which forms the basis of the
lab work. Currently more than 40% of students report spending more than 15 hours a week on
354, and we suggest that a solid but less excessive workload be a goal of any revision. There are
persistent rumours of excessive collusion on the programming assignments, and we are
unconvinced that the students who might decline a second systems course under the self-directed
scheme are really reaping much benefit from the present situation.
This leaves the non-core material in CS 342 for the specialization course Sys 2. We would
suggest as an example the approach taken in SCS 337. Students also report spending a lot of time
on CS 342, though the numbers are lower, and fewer of them are inclined to rate the course as
requiring too much work. But many students decide at about this time to lengthen their program
of study from eight to nine or more terms, spreading out the workload by taking fewer than five
courses a term. Given that Sys 2 will not be a core course, its workload can rise somewhat above
the norm for courses at its level without having too deleterious an effect. We believe a significant
number of students will choose to take Sys 2 voluntarily, either out of interest, or because it may
be a prerequisite for some fourth-year CS courses.
3.3 Algorithms and data structures courses
The combination of CS 341 and CS 360 together make core overweight in advanced algorithms
and complexity. The problem is with CS 360. Historically, this material was part of many
undergraduate programs, but increasingly it has moved to being a specialized topic. Finite-state
machines and context-free grammars are still vital, but they can be studied in application
contexts (programming language compilation and sequential circuit synthesis), which is what is
currently done in CS 241 and CS 251.
Out of the 36 hours in CS 360, 30 are not in the Steelman core, and not core in any examined
self-directed program. The remaining 6 hours, an introduction to computability and the halting
problem, are in the Steelman core, and we suggest retaining this material in the CS core by
moving it to CS 341 as a warmup to the treatment of NP-completeness.
Some of the material in CS 341 is also outside the Steelman core. It also creates an awkward
situation when the same topics are revisited in more depth in CS 466. We suggest removing 8 to
10 hours of advanced algorithmic material from CS 341, including amortized analysis,
randomized algorithms, and approximation algorithms. These topics can be moved to CS 466.
The remainder of CS 341 mostly adheres to the core. CS 360 will become a specialization
course, and it can be filled out with material that is often neglected (eg proper coverage of
recursively enumerable languages and their complements, and the uncomputability hierarchy).
3.4 Scientific computation courses
Scientific computation, formerly known as numerical analysis, was also historically a part of
most CS programs; in fact, a popular approach in a first computing course was to have the
students write algorithms for numerical approximation or integration in FORTRAN. But in
recent times, this material has increasingly become a specialized topic. The current content of CS
370 is not in the Steelman core, or in the core of any examined self-directed program. In the
context of the interplay between CS and mathematics, this course is central, and we recommend
that it remain core for the BMath(CS) program we describe below. The similar course CS 371
(with a somewhat different approach) will be core for the new Computational Math program. By
removing CS 370 from the core, it is possible to restore the prerequisite of Math 237 that it once
had.
It remains important to show students that real numbers cannot be exactly represented in a
computer, that manipulating floating-point numbers requires new algorithms, and that roundoff
and numerical stability are serious issues. Some of that is done in the new CS 251, which now
contains material on floating-point representation (the IEEE 754 standard), on algorithms for
floating-point addition and multiplication, and on the need to keep guard and round bits in
intermediate results to avoid roundoff errors. In addition, the modified first-year Math courses
will emphasize computational aspects of algebra and calculus (e.g. Taylor series for
approximation, interpolation, numerical integration, Newton's method), and might even discuss
numerical stability.
3.5 Distribution requirements
We propose distribution requirements on both the specialization CS courses and the non-Math
and free choice courses. These requirements are intended to ensure quality and to send a message
to students that these credits are important to their education and should not be wasted on the
easiest courses they can find in the calendar.
3.5.1 Requirements on specialization CS courses
With the current roster of CS 3xx and 4xx courses, it is hard to construct programs that are
highly imbalanced; there simply aren't enough choices. But this could change as more 3rd and
4th year courses are developed, and we should put rules in place now that embody the spirit of
our vision for the degree. We need to limit the number of CS courses taken in total (with more
free choices, this is an issue), and we want to ensure a mix between 3rd and 4th year, and across
areas. The situation is complicated by the presence of CS 7xx courses which should count
towards the B.CS for good students. These reasons suggest the following rules:

At least 3 CS 4xx or CS 7xx courses.

At most 10 total CS courses above and beyond the core (19 total maximum).

Grad courses can only be taken with explicit consent of an advisor.

If more than one grad course is taken, an advisor must approve a student's entire selection
of specialization courses. (We expect this to be rare.)
These rules do not address the question of excessive concentration in one area. CIPS
accreditation rules (see the B.CS Web page) forbid this, but the categories used there are
criticizable. We prefer to use different categories, though choices fitting our rules should also
satisfy theirs. The categories implied by the "middle digit" system are also problematic, and this
system may not be sustainable, depending as it does on a modest number of courses in any broad
area. We suggest the following rule:

At least one course from at least two of the following areas:

Systems and SE: Systems 2, 442, 444, 445, 446, 447, 450, 452, 454, 456, 457

Applications: 448, 486, 488, Computer Vision

Mathematical Foundations of CS: 360, 370, 462, 466, 472, 476, 487
Not all the 4th year courses have been placed in one of the above areas. The intention of these
lists is to ensure a modest amount of breadth in specialization courses. Courses like CS 480 or
CS 492 are broad enough that they cannot be taken as part of an excessively narrow selection.
New courses that are proposed should be assigned to an area (or not assigned at all) with the
spirit of this requirement in mind.
3.5.2 Requirements on non-Math courses
There are two legitimate but potentially conflicting goals one might have for effective use of
non-Math courses: breadth and depth. If someone is trying to do an entire second major or fulfil
a joint requirement, their task should not be made difficult or impossible by breadth
requirements. Students should also not be permitted to simply take "101" courses in a number of
different areas without ever exploring any of them in more depth. We suggest that students
should satisfy at least one of requirements 1 or 2 below:
1. (Serious depth)
Fulfil the requirements for a minor, joint, or full honours program outside Mathematics; OR
2a. (Breadth)
At least two courses from Arts group A (Humanities)
At least two courses from Arts group B (Anthropology, Economics, Geography, Political
Science, Psychology, Sociology)
At least one course from Science
At least one course from Science, ES, or AHS
AND
2b. (Depth)
Three 3rd year courses in one non-Math department; OR
Three courses forming a prerequisite chain of length 3; OR
A coherent plan approved by a CS advisor
The Arts group A and B classifications are used for breadth in programs leading to a Bachelor of
Arts, and are described in the calendar. We were somewhat worried about the science
requirement; while we feel it is important, introductory courses in Chemistry and Physics require
the corresponding OAC credits (and will probably require Grade 12 credits from 2003 on). Our
design team member with experience in admissions believes that more than a negligible number
of our students have neither. There are a few Biology and general Science courses open to those
students, but this situation should be carefully monitored to avoid this requirement becoming too
restrictive or onerous.
3.6 Upper-year courses, options, and other programs
We need to review the prerequisites needed for all specialization courses and make sure they are
accurate. Some adjustment of content will be needed in some of them; for example, CS 454 and
CS 456 may change slightly depending on how Sys 2 looks and whether it contains any network
concepts. Similarly, CS 462 and CS 466 need to change somewhat as a result of the changes to
CS 341 and CS 360. CS 450 is due for updating as a result of the recent changes to CS 251.
All 4th year courses should be subject to a proper quality assurance process to ensure that they
do not lead to weaknesses in the program. It may even make sense to give some of them 3rd year
course numbers. CS 448 (Databases) might benefit from this approach, and many students have
suggested a one-term survey of software engineering. We recommend that CS 494 be converted
to a MTHEL (math elective) course; its weaknesses were discussed in section 1.4, and the
sessionals who teach it do not seem willing to alter their delivery to bring it into line with the
way other 4th year CS courses are taught.
The self-directed approach allows students to take responsibility for crafting their education. We
believe that it is unnecessary to offer many options that show up on diplomas and transcripts.
Doing so creates an atmosphere where the credential is valued over the actual content of the
courses and the skills imparted, and disadvantages the student who pursues breadth or constructs
their own concentration which simply lacks a formal name. The only reason to have such
options, bureaucratically, is if access to certain courses outside CS is limited and requires
commitment to an option. This would argue for continuation of the Digital Hardware Option, for
example. The Software Engineering and Information System options should be replaced by
suggested concentrations, which would not appear in the title of a degree. Students could still
discuss these in their CVs, if they were seen to be valuable.
We have not examined the Bioinformatics program in detail, but it may make sense to replace
the BMath(CS) Bioinformatics option with a B.CS Bioinformatics option. Alternately, if the new
B.CS proves to be compatible enough with the joint Honours Bioinformatics program, the option
can simply be removed.
3.7 Justifications for other CS and Math core courses
In this section, we briefly discuss the CS and Math courses required in the proposed B.CS
program but not mentioned above.
CS 130 and CS 134 are standard object-oriented CS 1 and CS 2 courses, and fit well with
courses suggested by the Steelman report (CS 111o, CS 112o) and with practice at most other
institutions. There are many possible choices of textbooks, languages, and programming
environments. One can question the speed at which advanced OO concepts are introduced, but
the course is open to tinkering without requiring drastic redesign.
CS 241, the "baby compilers" course, is an unusual course in a global context. It has some of the
aspects of a first course in computer organization (such as the Steelman course SCS120s) but
goes deeper into the process of parsing and code generation. We feel it provides a nice mix of
practice and theory; finite-state machines and context-free grammars are introduced with good
motivation, and the data structures studied in CS 134 are utilized.
CS 251, the architecture course, was redesigned in 2001 with recommendations from the
Ironman report (Steelman's predecessor) in mind. It looks very much like SCS 220. The material
in this course could easily be combined with that in CS 241 into a coherent two-course sequence,
taken either sequentially or in parallel. Currently most students take CS 241 and CS 251 at the
same time, but the courses do not yet fully mesh. CS 251 could be moved earlier in the
curriculum, but moving it into first year would violate the principle that all Math faculty students
should have a common first year for purposes of transferability. We did not feel it necessary to
precede CS 251 with a course in digital design, though a followup specialization course (perhaps
taught with cooperation from ECE) might make sense.
CS 246 treats the important topics of programming in the medium and software engineering, and
is necessary to lay the foundations for the more challenging of the upper-year systems courses.
Care needs to be taken to avoid overlap with CS 130, since many of the topics from that course
are revisited in CS 246, but in more depth.
CS 240 is not a standard data structures course; it is also a mix of practice and theory, with topics
such as memory management, hashing, string matching (another good use of finite automata),
and with nontrivial programming assignments. Some advanced topics could be removed without
weakening the core.
From the above description, we conclude that while there may be a few hours that can be
trimmed from our core here and there, it is not really possible to remove an entire course and still
match our benchmarks for core content without a considerable amount of course redesign.
Math 135, the classical algebra course, is difficult to justify just from the list of topics, but it is
one of the most successful courses in the Faculty, having been polished over more than two
decades. It is the underlying subtext of this course that is important: it delineates for the student
the difference between doing mathematics in high school and doing mathematics in university.
As such, it is crucial for subsequent Math courses and for any treatment of formal methods in CS
courses.
Math 136, the first course in linear algebra, treats topics necessary for many upper-year Math
and CS courses, such as matrices, linear transformations, vector spaces, and solving linear
equations.
Math 137 and Math 138 are courses in calculus. We feel that calculus is somewhat of a sacred
cow; it is useful in engineering and science courses where the real world must be described and
analyzed, but it is perhaps of less use (though definitely of some use) in the human-constructed
digital world. Nevertheless, the mental exercise it gives students is valuable, and the goal of
maintaining a common first year is worthwhile. The changes to these courses discussed above
will emphasize the connection between discrete and continuous mathematics, and the
computational aspects of calculus.
Stat 230 is a first course in probability. Probability is a valuable tool in both theoretical and
practical courses, and is definitely core in the Steelman report. We feel that lumping basic
probability and statistics together in one course, or even throwing in counting, graph theory, and
logic as some institutions do, would result in excessively shallow coverage and would be a waste
of the resources offered us by being in a Faculty of Mathematics. Without a good grounding in
probability, students are reduced to relying on intuition which is often wrong, and must accept
statistical tests on faith without understanding their basis and limitations.
The material in Stat 230, Stat 231, Math 239, and the Logic and Computation course is usually
covered in other programs in three or fewer courses. Much as we would like to reduce the course
count, we find it difficult to see how this material can be distributed among fewer courses
without seriously compromising both the ability of students to apply the material and the
pedagogy of those courses.
4. Renewing the BMath(CS)
The thick core approach has resulted in a tug-of-war between CS and Math for precious
curricular space, with the paradoxical result that the BMath(CS) degree has a high math content
but its claim to be a degree in mathematics is significantly weakened by the degree of choice
permitted and the absence of key required math courses. The self-directed approach allows a
move closer to the ideal of what a BMath(CS) might be, namely a degree with decent
concentration in both CS and math. In effect, we are taking advantage of the flexibility inherent
in the self-directed approach to strengthen a special and historically important interdisciplinary
program, namely one combining CS and mathematics.
The new BMath(CS) cannot be called self-directed, because of the relative lack of choice, but
this would be true of any interdisciplinary program built from the B.CS without significantly
sacrificing CS content. Our goal here is to improve the BMath(CS), in ways that will be
considered beneficial by both the CS department and the rest of the Math Faculty. The result is a
program that is clearly distinct from the self-directed B.CS, which should make it attractive to
students who value mathematics.
New BMath(CS) degree [to go with proposed self-directed B.CS]:
12 Math courses: Math 135, 136, 137, 138, 235, 237, 239, Stat 230, 231, 3 others (either from
short list of "real" math courses e.g. group theory, real and complex analysis, mathematical
optimization, applied probability; or as part of a minor, joint, or double honours)
11 CS core courses: CS 130, 134, 241, 251, 240, 246, 341, 360, 370/371, Logic/Comp, Sys 1
[see above notes]
4 CS specialization courses: CS 3xx, 4xx, 7xx (at least 3 from 440-489)
10 Non-Math courses (with distribution requirements)
3 Free-Choice courses
5. Rationales for BMath(CS) changes
Here, we briefly discuss the rationales for the proposed changes to the B.Math(CS) degree. Note
that a current BMath(CS) student could make choices which match the future BMath(CS)
requirements, were Logic and Computation available to them, but not all such choices will work
(that is, the new BMath(CS) is more restrictive). Future B.CS students will also be able to move
to the new BMath(CS) easily at the end of their 2A term, and later if they make judicious
choices.
5.1 Math content
We have put Math 237 (Calculus 3) back into the BMath(CS) core. It was there for most of the
degree's history, until it was sacrificed to make it possible to take more than one CS course a
term in second year. This was not easily accepted by the Math Faculty, and we believe that the
restoration of Math 237 to the BMath(CS) will make the B.CS more acceptable. Many of our
students (certainly those taking double honours, but others as well) take it as one of their three
extra required Math courses. We have also retained Math 235 in the BMath(CS) core; it was
removed from the B.CS requirements.
The current BMath(CS) requires three extra Math courses, but does not place any restrictions on
them. This is a concession to deal with reluctant students forced to take these three courses in
order to take CS; it weakens the claim of the BMath(CS) to be a true Bachelor of Mathematics.
Not all students take the easiest math courses they can find, but many do. Given that the B.CS is
available to these reluctant students, we recommend having these courses in the new BMath(CS)
chosen from a short list of more serious courses developed in consultation with other
departments in the Math Faculty. Students doing a minor, joint, or double honours in another
department should not be subject to any such requirement, as they are already demonstrating
their seriousness.
5.2 Mathematical CS content
The BMath(CS) should naturally contain the more mathematical and theoretical of the 3rd year
CS courses. We recommend that both CS 360 and CS 370 remain core for the BMath(CS), even
though they have been removed from the B.CS core.
5.3 Other details
The specialization requirement of four 4th year CS courses in the current BMath(CS) program
has been slightly relaxed here to include 3rd year courses. Currently the only one would be Sys
2, though a User Interfaces course (CS 498R, developed to be a second year course in the joint
SE program) could be added, and other 3rd year courses may be proposed later; alternately, the
current requirement of four 4th-year CS courses (or Sys 2) could be retained, and additional 3rd
year courses could be free-choice.
The non-Math courses should be taken seriously as well, but the program is more constrained, so
a freer choice than offered for the B.CS might be permitted here. We suggest either the same
formula as for the B.CS (req 1 OR [req 2a AND req 2b]), or a slightly looser formula (req 1 OR
req 2a OR req 2b).
6. A 3-year general program in CS
For the purposes of this proposal, we will call this program the General B.CS, though it almost
certainly cannot be called this in practice, as the name does not distinguish it enough from the
B.CS above. We need a different name, such as Bachelor of Information Technology, by the
time the final proposal is approved. We have not specified a complete program here, because it
requires the commitment of additional teaching resources and the creation of new courses, and
the department has to have a separate discussion as to whether this is worthwhile.
A considerable number of our students that want to stay in the Faculty are forced from Honours
Computer Science to the General Mathematics program because they struggle with the math
content in their first two years. Ironically, this means that they must take more math and less
computer science in order to obtain their degree. They need a fallback option that matches their
interests. Until our attrition rate decreases dramatically, there will be more than enough students
interested in a General B.CS degree. These are talented students, as demonstrated by their
acceptance into our program, and it does not make sense to simply lose these students.
A General B.CS degree would increase our accountability to our CS minor programs and
sometimes neglected non-major courses. Though we have not specified a complete program, we
doubt whether the completion of our line of reasoning would very much affected by the selfdirected philosophy of the B.CS above; we have not seen the comprehensive proposal at the time
of writing, but we would not be surprised if a similar program below could be added to that as
well.
6.1 The current General Mathematics program
The current General Mathematics program requirements include:
1. 30 total courses
2. at least 16 Math courses
3. at least 10 non-Math courses
At least 10 (or one third) of courses must be non-CS math. This means that students may take at
most 10 (or one third) CS courses. In total, there are about 15 non-specialist CS courses to
choose from.
The theory behind the General Math program is that it is for students wanting a less intense
education than that provided by an Honours program, and for students unable to meet the
requirements of the Honours program. In practice, it is much more for the latter group of students
than the former. This will likely be the case for a General BCS program as well, and students
should not be directly admitted into it.
6.2 Towards a General B.CS program
It seems reasonable to assume that the proportion of CS, non-CS Math and non-Math courses of
the General B.CS program should be comparable to that of the Honours program, while
preserving the non-Math content of the Math General program. This suggests a mix of
approximately 10 CS, 6 non-CS Math and 10 non-Math. The problem is that we do not have
enough CS non-major courses to offer a reasonable core plus some choice totalling 10 courses.
The ones that might fit (together with permitted major substitutions) are:
CS 113 (CS 130)
CS 114 (CS 134)
CS 234 (CS 240)
CS 230 (CS 241)
CS 330 (Management Information Systems)
CS 338 (Databases)
CS 430 (Applications Software Engineering)
CS 432 (Business Systems Analysis)
CS 436 (Distributed Computer Systems)
CS 437 (Computer Simulation of Complex Systems)
At least two or three more CS non-major courses are needed, as some of the courses above
should not be core in a General B.CS program. One obvious suggestion is a non-major
equivalent of CS 246. Developing and offering these courses would take a serious commitment
of resources, and we hesitate to make further recommendations without broader discussion of the
merits of the idea.
The Math requirements could be:
MATH 127 (MATH 137)
MATH 128 (MATH 138)
MATH 125 (MATH 136)
MATH 126 (MATH 235)
Two more from the General Math short list, excluding the CS courses
The English language requirements, average requirements and limits on failures and course
attempts should be the same as for the General Math program.
Appendix A: References
B.CS Web page: http://www.cs.uwaterloo.ca/admin/curric/bcs/
Overview of programs at other institutions:
http://www.cs.uwaterloo.ca/admin/curric/bcs/overview.html
Overview of self-directed programs at other institutions:
http://www.cs.uwaterloo.ca/admin/curric/bcs/sd-overview.txt
Steelman draft of ACM Computing Curricula 2001:
http://www.computer.org/education/cc2001/steelman/cc2001/index.htm
Knowledge modules in Steelman core and their coverage in current BMath(CS):
http://www.cs.uwaterloo.ca/admin/curric/bcs/Steel-in-CS.txt
Content of current BMath(CS) core courses in Steelman module terms:
http://www.cs.uwaterloo.ca/admin/curric/bcs/CS-in-Steel.txt
Systems courses at UW compared to Steelman and other institutions:
http://www.cs.uwaterloo.ca/admin/curric/bcs/sys-comp.txt
Comments can be sent to Prabhakar Ragde (plragde@uwaterloo.ca)