Dan Brown, Mark Giesbrecht, Naomi Nishimura, J.P. Pretti, Geoff Pounder, Prabhakar Ragde
December 12, 2001
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.
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.
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 self-directed 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.
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 48-credit 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.
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 time-consuming. 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.
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.
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.
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 Canadian departments almost certainly
including the top 5 in CS research. 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.
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
self-directed 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.
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
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:
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.
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.
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.
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).
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.
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.
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:
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:
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.
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:
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.
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.
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.
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.
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
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.
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.
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).
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
self-directed 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.
The current General Mathematics program requirements include:
1. 30 total 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.
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)
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)
The English language requirements, average requirements and limits on
failures and course attempts should be the same as for the General
Math program.
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
2. The self-directed program proposal
Current BMath(CS) degree
New self-directed B.CS degree:
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
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
Three courses forming a prerequisite chain of length 3; OR
A coherent plan approved by a CS advisor
3.6 Upper-year courses, options, and other programs
3.7 Justifications for other CS and Math core courses
4. Renewing the BMath(CS)
New BMath(CS) degree [to go with proposed self-directed B.CS]:
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
5.2 Mathematical CS content
5.3 Other details
6. A 3-year general program in CS
6.1 The current General Mathematics program
2. at least 16 Math courses
3. at least 10 non-Math courses
6.2 Towards a General B.CS program
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)
MATH 128 (MATH 138)
MATH 125 (MATH 136)
MATH 126 (MATH 235)
Two more from the General Math short list, excluding the CS courses
Appendix A: References
Comments can be sent to Prabhakar Ragde (plragde@uwaterloo.ca)