Download 331-k3-df.doc

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts

Computational complexity theory wikipedia , lookup

Theoretical computer science wikipedia , lookup

Genetic algorithm wikipedia , lookup

Algorithm characterizations wikipedia , lookup

Mathematical optimization wikipedia , lookup

Multiple-criteria decision analysis wikipedia , lookup

Corecursion wikipedia , lookup

Recursion (computer science) wikipedia , lookup

Pattern recognition wikipedia , lookup

Pattern language wikipedia , lookup

Transcript
Assessment Item K3 – Recursive and Pattern-Based Algorithmic Design – CS331
Skill being assessed: Ability of the student to design and implement recursive algorithms and to
discover and apply common computational patterns
Program outcome to which this skill is mapped: (k) An ability to apply design and development
principles in the construction of software systems of varying complexity.
Performance Assessment Abstract: While software developers should be familiar with the classic
object-oriented design patterns, they should also be familiar with classic functional patterns of
computation such as the map pattern, the select or filter pattern, and the accumulator, reduce or folding
pattern. These computational patterns abstract away the details of recursive algorithms. While these
patterns take advantage of higher-order functions that are typically available in functional programming
languages, they can also be applied to any collections of objects in non-functional programming
paradigms. In this exercise, students are asked to:
1. Design a recursive algorithm sufficiently detailed that anyone else could implement the
program from it. Given the functional specification of a problem in terms of inputs, at least one
of which is a list, and outputs, the student must produce a design document for a recursive
solution to the problem. This design must describe precisely:
 how to partition some input into two or more subsets [problem decomposition]
 how one or more of the subsets can be processed using the function being defined
[recursion on smaller problem]
 how the remaining subset of the input can be processed directly [non-recursive
computation]
 how the recursion bottoms out [base case]
 how to combine the solutions to the non-recursive and recursive subsets to obtain the
final solution to the original problem [solution recombination]
2. Implement and test their recursive design as generally and elegantly as possible.
3. Solve the same problem non recursively. Given the same functional specification of the problem
in terms of inputs, at least one of which is a list, and outputs, the student must identify the most
“natural” computational pattern among those listed above and implement it correctly and
elegantly.
Rubric for Evaluation
Criteria
Design
document for
the recursive
solution
Implementation
of the recursive
solution
Implementation
of the patternbased solution
Exemplary
The student
produced a
complete and
correct design
document with a
detailed description
of each one of the
five steps: problem
decomposition,
recursive and nonrecursive subproblems, bottom
case, and solution
recombination.
The student
produced a correct,
concise and elegant
recursive
implementation.
The student
produced a correct,
concise and elegant
non-recursive
implementation
(typically a oneliner) that uses the
most appropriate
computational
pattern.
Satisfactory
The student produced a
correct design document
in which all five
components are
discussed but one or two
of them lack details
(e.g., solution
recombination is
vaguely described, not
saying clearly whether
lists of lists must be
appended or cons'ed).
Marginal
The student produced
a mostly correct
design document but
one or two of the five
required components
are omitted altogether
or are too vague to
assess for correctness.
Deficient
The student produced no
design or their design
exhibits one or more
major flaws and will not
produce the correct output
in some cases, or is so
vague that it would not be
possible to implement it
with the available
description.
The student produced a
correct implementation
but their solution is not
as concise as possible
(e.g., it does not use
pattern matching to its
full potential or it
includes one or two
unnecessary
patterns/cases).
The student produced a
correct implementation
but their solution is not
as general as possible
(e.g., it imposes
unnecessary type
constraints) or as
concise as possible (e.g.,
it uses a named local
function instead of an
anonymous one) or it
stretches the
applicability of a pattern
(e.g., uses folding where
mapping was the
obvious pattern).
The student produced
a mostly correct
implementation that
fails in a small number
of special cases (e.g.,
wrong answer or
exception raised).
The student produced an
implementation that does
not compile or produces
the wrong output or raises
an exception in a large
number of test cases.
The student produced
a mostly correct
implementation that
fails in a small number
of special cases (e.g.,
wrong answer or
exception raised).
The student produced an
implementation that does
not compile or produces
the wrong output in a
large number of test cases.