Create a gist now

Instantly share code, notes, and snippets.

What would you like to do?
Specifications for Student Work for MTH 201 (Calculus)

Specifications for Student Work in MTH 201

Specifications for Pass/No Pass work on Guided Practice, Concept Quizzes, and WeBWorK

The rules for determining Pass/No Pass work on these three items are very simple:

  • A Pass on Guided Practice is awarded to responses to Guided Practice items in which a good-faith effort to be right is given on all items, and the submission is given before the deadline. A No Pass is awarded if the submission is turned in after the deadline. A No Pass is also awarded if at least one item in the exercise set is blank or does not show evidence of a good-faith effort to be correct, for example if the response is "I don't know". Please note that mathematical correctness is not a factor; you are free to be wrong about an item as long as you show evidence of trying to be right.
  • A Pass on a Concept Quiz is awarded if 8 out of 10 questions are answered correctly; otherwise the mark is No Pass.
  • WeBWorK problems are the one item in the course that are graded using points. Typically each problem is worth 1 point, awarded in full if the answer is correct and 0 otherwise. (Some WeBWorK questions that involve multiple items to answer on a single question will allow partial credit.)

Specifications for work on Problems and Miniprojects

Problems and Miniprojects differ from other work in the class in that they involve written communication, and not just giving answers to problems. Therefore the specifications for work on these items are more complex and focus mainly on writing, communication, and style. Recall that work on these items is assessed at one of three levels -- Mastery, Progressing, or Novice.

General rules for Mastery level work on Problems and Miniprojects

Attaining Mastery level on one of these items requires that you be aware of the four different kinds of error that can occur when doing significant work in mathematics.

  1. Computational error. This occurs when a mathematical computation (calculus, algebra, arithmetic, etc.) is incorrectly carried out, either by hand or on a computer. For example: Given the equaton 3x = 9 and arriving at x = 2 is a computational error.
  2. Logical error. A logical error occurs when a conclusion is drawn erroneously from a set of information. For example: Given the equation x^2 = 9 and concluding that x must be positive is a logical error. In calculus, if you are given the derivative equation f'(5) = 0, and then conclude that f must have a local extreme value at x = 5, this is a logical error.
  3. Syntax error. Syntax errors occur in one of two ways. First, they can occur as errors in English grammar, when the rules for language usage are not followed correctly, especially to the point that they obscure the thought process in the solution or introduce new errors. Second, they can occur as errors in the usage of mathematical notation, especially if the misuse of notation obscures the solution or introduces new errors. For example, in calculus the misuse of the pronoun "it" without clear reference to an antecedent is a particular problem (example: "It is increasing because it is positive"). In mathematical notation, syntax errors can be caused by switching variables mid-solution (for example, solving 3t = 9 to get x = 3 is an error); by misusing function notation, mismatching parentheses, and a host of other possibilities. (Note: WeBWorK in particular has no mercy when it comes to syntax error.)
  4. Semantic error. Semantic errors occur when the rules of the grammar of a language are followed but the resulting statements are nonsensical or meaningless. For example, the statement "Colorless green ideas sleep furiously" is correct English syntax but has no meaning, therefore it represents a semantic error. In mathematics, a similarly semantically erroneous statement would be "The following graph can be factored". This is a semantic error because we don't "factor" graphs; we factor polynomials and integers, and to say we are "factoring a graph" is meaningless.

In reality, these errors are closely linked together, and an error in one category usually introduces an error in one of the others. The general rule for MTH 201 is: Work on Problems and Miniprojects must be almost, if not entirely free of all of the above kinds of error in order to be assessed as Mastery level; and there can be no significant instances of any of these errors. That is, a small number of minor errors can be tolerated as long as they do not make the answer incorrect (for Problems) or significantly obscure the thought process in the solution. But large numbers of minor errors, or a single instance of a major error, will result in the work being marked as Progressing at best.

For these items, we will often refer to the standard audience for MTH 201, which is defined to be:

The standard audience in MTH 201 consists of classmates in MTH 201 who are familiar with the mathematical ideas discussed in the class and have the appropriate background knowledge for the class, but who are unfamiliar with the particular problem whose solution you are presenting and therefore need to be persuaded that your solution is correct and your conclusions believable.

Therefore some items will not need to be discussed in a solution; for example, if a problem involves solving 3x - 4 = 5 for x, you can jump straight to x = 3 without showing work. But for example, if a problem is asking you to compute a derivative using the Chain Rule, you will need to show all the calculus steps because the standard audience has not seen your problem. (You could skip the algebra steps needed to simplify the solution, but then you must be 100% assured that your simplified answer is correct.

In addition to the above, here are some special rules for other aspects of your work on Problems and Miniprojects.

Specifications for supporting work

In Problems and Miniprojects it is crucial that you not only give an answer or a conclusion but also clear, complete, and correct work that backs up your answer or conclusion. Submitted work that consists only of answers will be considered a "significantly incomplete" in the language of the syllabus.

  • For Problems in which you are asked for a clearly-defined answer to a computational problem, the answer must be clearly indicated (for example, by drawing a box around it), and there must be supporting work free of significant gaps for the standard MTH 201 audience that clearly supports your answer.
  • For Miniprojects in which there may not be a single right answer but rather a conclusion or analysis you are asked to perform, the conclusion you are asked to draw or analysis must be clearly indicated (for example, by setting it off in a separate section of your writeup), and there must be supporting work free of significant gaps for the standard MTH 201 audience that clearly supports your conclusion.
  • Answers or conclusions that are given that have only minimal supporting work, or for which the relationship between the answer/conclusion and the supporting work is tenuous, illogical, or unclear will be marked at Novice level and returned without further feedback.

Specifications for formatting submissions

  • Submissions of Problems and Miniprojects must be either typed or neatly handwritten and submitted via Blackboard as PDF files. Files that are submitted in some other form besides PDF will be marked at Novice level and returned to the author without feedback.
  • Each Exam or Miniproject will include a cover page that states the file name to use when submitting it. Files that are submitted with the incorrect file name will be marked at Novice level and returned to the author without feedback.

Specifications for graphical elements

The following specifications apply specifically to graphs of functions:

  • Graphs must be situated in a viewing window that shows all the important facets of your graph and which does not include excessive "dead space".
  • Both axes of the graph must be clearly labelled with three pieces of information: the quantity being represented, the variable name, and the units. A recommended way to format this information is Quantity (variable) [units] For example, a graph of a function v(t) that gives velocity v as a function of time t would have the horizontal axis labeled Time (t) [seconds] and the vertical axis labeled Velocity (v) [m/sec].
  • Both axes should include tick marks that are sufficiently labeled to show the scaling. Choose scale increments for both axes that are easy to read.
  • If you are graphing more than one function on the same set of axes, each individual function must be clearly labeled.

Graphs that are included in a writeup for a Problem or Miniproject must satisfy all of these stylistic elements in order to be marked at Mastery level unless the context of the problem prohibits one or more of these elements being met. For example, if you are asked to draw a graph of a function but the function does not correspond to any real-world relationship and does not have units, then obviously your axis labels do not need to include the quantity or the units. (But they should include the correct variable name.)

For other graphical elements, such as diagrams or pictures, the element must be clearly labeled (preferably with a caption) and neatly rendered.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment