No abstract available.

No abstract available.

At recent SIGCSE conferences, there appeared to be a refreshing revival of interest in game theory as a valuable pedagogical tool for educators [4,5]. Games can serve as an excellent resource for CS0, CS1, networking, user interface and software engineering projects. Games can be utilized to motivate students, enrich their intuition, and illustrate fundamental principles of algorithm design such as exploration of regularities, modularity, correctness, and efficiency. Many CS instructors look for ways to motivate, improve intuition, and illustrate the subject matter they teach, and games are a wonderful means of doing so.

The Indiana Student Software Awards Competition (ISSAC) was created to encourage students in the state of Indiana to improve their software development skills, to potentially consider a career in information technology, and to help stem the flow of graduates out of Indiana - "the brain drain". High school or college students who develop a software project for class, personal enrichment or corporate internships may submit a project. ISSAC 2003 is the third year of the competition. Finalist projects are judged at the annual Indiana Technology Summit, and students are awarded scholarships and plaques based upon the overall quality and functionality of their software.

No abstract available.

Throughout the history of computer science education there has been debate on what should be the appropriate mathematics background for computer science majors. The first computer science instructors were mathematicians and the first curriculums were just modifications of mathematics curriculums. However, as the discipline has grown and matured there has developed several areas of computer science where traditional undergraduate mathematics is not used and traditional mathematics preparation may not be appropriate. Although logic and problem solving skills are valued by the Computer Science community, exactly how many hours of mathematics and what areas of mathematics should be required, needs to be addressed. This panel was convened to discuss this issue from a variety of viewpoints. We hope that discussion will give the listeners new ideas on just what should be the appropriate courses and topics for their institution and program. The panel was chosen to present a wide range of view representing a variety of schools (large and small, public and private, traditional and non-traditional, preparation for the workplace or for disciplines (E-commerce, distributed computing, artificial intelligence, software engineering and graphics) viewpoints (both young and old, industrial and academic).

"… women embrace the "precision" of mathematics." a quote from panelist Paul De Palma's viewpoint article "Why Women Avoid Computer Science" in the June 2001 CACM. Panelist Kim Kihlstrom notes "… I got into electrical engineering and then computer science exactly because I love math." Henderson's evidence indicates that women performed better than men in a mathematically oriented first course in computer science, and women felt the course was more beneficial than a traditional programming oriented first course. Regarding a mathematically oriented functional programming course for high schools Kathi Fisler says "Our high school teachers have noticed females preferring this to a conventional curriculum by as much as 5 to 1!"Coincidence, or is there a common thread here? Please join us for the discussion and share your own viewpoints.

The premise of this panel is that most introductory Computer Science courses are too narrowly focused on teaching students a programming language. This is a controversy that has been debated for years, but in recent years seems to have been forgotten. The writers of Computing Curricula 1991 stated:"Many feel that the amount of attention traditionally paid to the syntax of a programming language in the first course is excessive, and ought to be replaced with a more balanced introduction to the discipline. For these reasons, PR: Introduction to a Programming Language is defined as a separate knowledge unit in Part II, but is not a required part of the common requirements. "[1]This panel will present a review of current, typical first year courses and evidence for the case against focusing those courses on the teaching of a programming language. Next, each panelist will present his or her philosophy for a first course, followed by details of the courses at their school that implement their view, and conclude with outcomes and evidence of success of the courses.The panel includes four experienced CS-1/CS-2 educators, two of whom are members of the Computing Curriculum 2001 Pedagogy Focus Group on Introductory Courses and Topics (including the chair), and two of whom are authors of introductory texts that do not focus on teaching a programming language.

There are deep connections between algorithmic and mathematical thinking. Both construct "systems" --- computing systems in the algorithmic case, intellectual ones in mathematics --- from simple primitives. As Knuth notes in the preface to The Art of Computer Programming, "The construction of a computer program from a set of basic instructions is very similar to the construction of a mathematical proof from a set of axioms" [1]. Other connections include similar ways of organizing primitives into larger structures (e.g., recursion in algorithms, recursion and induction in math; conditionals in algorithms, definition in cases and proof by cases in math), similar ways of using abstraction to manage complexity, and an underlying reliance on logic. In short, mathematics is not merely a tool for limited areas of computer science, it is a mindset that fundamentally improves one's ability to devise and implement algorithms. Computer science students therefore need to exercise their mathematical as well as their computational abilities, and computer science educators need to help students use both ways of thinking to solve computing problems.This panel illustrates specific ways in which mathematical reasoning enhances algorithmic problem solving, and provides educators with concrete examples and resources to use in their own teaching. Each panelist will present an exercise, classroom example, or similar item, from their own experience, and will demonstrate ways in which mathematical reasoning helps one solve and/or understand it. The audience will be invited to contribute their own examples and to comment further on the role of mathematical thinking in computer science problem solving.The panelists' and audience members' examples will be collected on a Web page for continuing reference. A prototype of this page is at http://www.cs.geneseo.edu/~baldwin/math-thinking/examples.html.

Many curricular guidelines, such as the Recommended Curriculum for Computer Science at Liberal Arts Colleges [4], suggest that students be exposed to many different programming paradigms (e.g., imperative, functional, object-oriented, declarative) in the undergraduate curriculum. Some institutions believe that students should have early exposure to many paradigms, often as early as the first two courses.Many institutions emphasize object-oriented programming early in the curriculum. Some also include functional programming. Imperative topics are often covered in courses that emphasize object-oriented or functional issues. Where does declarative programming fit? Sometimes not until an upper-level language paradigms course or artificial intelligence course. Sometimes it never fits, at least not explicitly.

necessity of formal methods education has developed from its increasing assimilation into systems development within industry. Organizations responsible for a wide range of applications have found it necessary to find an improved means of intellectual control over their complex system development and that formal methods can meet this need. To this end, the International Survey of Industrial Applications of Formal Methods concluded and recommended: The current educational base in the US is weak in teaching formal methods in the context of software engineering . . . There is a clear need for improved integration of formal methods techniques with other software engineering practices[2]There exists a number of articles in the current literature expressing the belief that the current educational program offered for a computer science degree does not stress the fundamental mathematical and engineering principles that should form the basis of software engineering[3,4,5,6]. theory learned in mathematics and science classes is applied in other engineering classes, but unfortunately has not been applied in software engineering. inability to apply logic in practical circumstances prevents the student from doing the systematic analysis necessary to solve practical problems.For these reasons, it is desirable to include the definition and application of a formal method into the undergraduate curriculum with the goal of increasing the complex problem solving skills of the software engineer. Formal analysis should be introduced early into the undergraduate curriculum to ensure substantial learning, use, and training in formal methods application.

We are concerned about a view in undergraduate computer science education, especially in the early courses, that it's okay to be math-phobic and still prepare oneself to become a computer scientist. Our view is the contrary: that any serious study of computer science requires students to achieve mathematical maturity (especially in discrete mathematics) early in their undergraduate studies, thus becoming well-prepared to integrate mathematical ideas, notations, and methodologies throughout their study of computer science. A major curricular implication of this theme is that the prerequisite expectations and conceptual level of the first discrete mathematics course should be the same as it is for the first calculus course --- secondary school pre-calculus and trigonometry. Ultimately, calculus, linear algebra, and statistics are also essential for computer science majors, but none should occur earlier than discrete mathematics. This paper explains our concerns and outlines our response as a series of examples and recommendations for future action.

Over a period of thirty years there have been many curriculum reforms in the Undergraduate Computer Science curriculum. The ACM/IEEE-CS task force is currently working on the Curriculum 2001. In this struggle to define and develop this dynamic field of computer science, we have the opportunity to identify the foundations and related concepts of mathematics we would like to see in the new CS curriculum and introduce these in CS1 and CS2. Many standard topics of discrete mathematics can encourage the use of mathematical thinking when taught along with the CS courses. The more complex foundations and other theoretical topics may be introduced later in the curriculum. This session will present some of the views and examples in this direction. Our goal is not to eliminate the need of discrete math but to integrate it into the basics of CS so that the student will experience mathematical reasoning in the early stages of the development of CS topics. Currently discrete math is taught as one of the early math requirements and many students do not see the relationship between the programming concepts and these mathematical concepts. An early blend of these ideas of will provide a richer experience to CS majors and the new topics can be learned more quickly if the underlying theoretical concepts are well understood. The programming languages of choice can be introduced in separate laboratory components taken parallel to CS1 and CS2.We hope that we all can agree that CS is not just programming and we have a new discipline that must develop its basic theory rather than depending on other disciplines to do it for us. Someday, the courses we know now as CS1 and CS2 maybe known as University Computing I and II as we now have in some of the other sciences.

article Free AccessDiscrete mathematics as a precursor to programming Author: Peter B. Henderson Department of Computer Science, State University of New York at Stony Brook, Stony Brook, New York Department of Computer Science, State University of New York at Stony Brook, Stony Brook, New YorkView Profile Authors Info & Claims ACM SIGCSE BulletinVolume 22Issue 101 February 1990pp 17–21https://doi.org/10.1145/319059.319070Published:01 February 1990Publication History 19citation412DownloadsMetricsTotal Citations19Total Downloads412Last 12 Months140Last 6 weeks7 Get Citation AlertsNew Citation Alert added!This alert has been successfully added and will be sent to:You will be notified whenever a record that you have chosen has been cited.To manage your alert preferences, click on the button below.Manage my AlertsNew Citation Alert!Please log in to your account Save to BinderSave to BinderCreate a New BinderNameCancelCreateExport CitationPublisher SiteeReaderPDF

Standard ML is a state of the art functional programming language, with features that make it excellent for teaching recursion and problem solving at the introductory level. Among the many pedagogically interesting characteristics of ML are its simple and uniform syntax, its type polymorphism and type inferencing system, and datatype declaration facilities. With little formal ML instruction, after several weeks first year students were able to use recursively defined data structures and to define fairly powerful recursive functions in ML. Standard ML is highly recommended as a tool for teaching recursive problem solving in the context of a course on the foundations of computer science.

There have been numerous testimonies to the inadequacies of our educational system [83]. For undergraduate computer science educators, major concerns regarding student preparation include poor problem solving and critical thinking skills, weak mathematics background, an inability to convey thoughts and concepts, and a lack of motivation. These problems can be addressed in the introductory computer science course by developing an integrated approach to effectively teaching discrete mathematical foundations, fundamental computer science concepts, and problem-solving skills. This paper is conceptual in nature and introduces some specific examples of possible approaches to overcoming these deficiencies and problems.

An introductorycomputer science course is frequently the most difficult course in the curriculum to teach.Computer scicnre educators must st,ay abreast of rapidly changing trends, text books, technology and teaching techniques.This paper provides an overview and perspective of introductory computer science courses, surveys some trends, and presents new alternative approaches regarding organization, foundat.ionsand material.It is based on the premise that the introductory course should create strong foundations upon which students can build, and that the curriculum should teach student,s to build soft.warrsystems which people use and maintain, not.just toy comput.erprograms.The paper presents personal views and insights, motivates underlying concepts, and provides many usrful suggestions which have been successfully employed in such int.roductorycourses.

Functional programming has enormous potential for reducing the high cost of software development. Because of the simple mathematical basis of functional programming, it is easier to design correct programs in a purely functional style than in a traditional imperative style. It is argued that functional programs combine the clarity required for the formal specification of software designs with the ability to validate the design by execution. As such they are ideal for rapidly prototyping a design as it is developed. An example is presented which is larger than those traditionally used to explain functional programming. This example is used to illustrate a method of software design which efficiently and reliably turns an informal description of requirements into an executable formal specification.

Transformations of reducible flowcharts to REPEAT-EXIT or ${\text{RE}}_n $-charts and transformations of ${\text{RE}}_n $-charts to more structured forms are investigated. In particular, transformations within the hierarchy of flowcharts (D-charts, ${\text{RE}}_1 $-charts, ${\text{RE}}_2 $-charts,$ \cdots $, ${\text{RE}}_n $-charts, $ \cdots $) studied by Kosaraju [J. Comput. System Sci., 9 (1974), pp. 232–255] are presented. It is shown that the transformation of ${\text{RE}}_n $-charts to D-charts requires at most $\lceil \log _2 (n + 1) \rceil $ auxiliary Boolean variables (flags), and that for each $n \geqq 1$ this bound is tight for at least one ${\text{RE}}_n $-chart. The existence of a hierarchy of flowcharts with respect to the number of flags needed for conversion into equivalent D-charts is also shown.

Abstract This report describes a macroprocessor, ‘Supermac’, and its use for modularization of large programs. The development of the macroprocessor and its application to program modularization was undertaken in a research project sponsored by GEC Telecommunications, Coventry, and this document forms the final report of that project. The project arose from the wish to be able to structure large pieces of software, written in a conventional programming language, in order to make them more easily understood and hence more easily constructed, maintained and modified. In this report the use of the specially developed Supermac macroprocessor to achieve better structured programs will be described in detail. A full definition of the Supermac notation.

A basic question m the area of asynchronous computation is.Given a synchromzaUon problem, what synchromzation primitives are needed for an "efficient" solution9 This paper is directed toward answering this question by providing characterizations of those synchronization problems solvable by DIjkstra's PV system of primitives and its various generalizations including PVgeneral, PVmultlple, PVchunk, Vector Addmon, and Loopless Penn Net systems These characterizations form the foundations of a formal synthesis procedure for determining effioent solutions to synchronization problems

Many of the process synchronization problems studied in the literature are of the form of a conjunction of finitely many conditions of the type “process $p_i$ blocks process $p_j$”. Such problems may be expressed as directed graphs whose nodes represent the processes and where there is an edge from node i to node j if and only if process $p_i$ blocks process $p_j$. We characterize the class of graphs which correspond to the system of synchronizing primitives of Vantilborgh and van Lamsweerde in terms of a normal form representation and present an efficient algorithm for determining whether an arbitrary graph is in this class.

A basic question in the area of asynchronous computation is: Given a synchronization problem, what synchronization primitives are needed for a solution? This paper is directed toward answering this question by characterizing the "behavior" of synchronization systems incorporating PV, PV multiple, PV chunk and PV general synchronization primitives.