This document can be found online:
- On Blackboard under
Course Documents > MTH 325 Specifications for Student Work - As a Github Gist: https://gist.github.com/RobertTalbert/860c0e53ab1184c447a9
- At the MTH 325 Github repository
The rubrics below are used to determine whether your work on various assessments receives a Pass or No Pass mark. Therefore you should keep a copy of these specifications nearby when doing your work and make yourself familiar with them.
In what follows, we will define the standard audience for MTH 325 to be:
Classmates in MTH 325 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.
Most Concept Check items will be objective in nature (true/false, multiple choice, etc.) where only the answer is graded. The sole specification for this work is that the answer must be correct and clearly indicated on the Concept Check form.
These are done during timed assessment periods and address CORE-M objectives, which are usually computations or construction of examples. Your work on these problems must follow these specifications:
- The solution to the problem must be correct, and the steps in the solution must also be correct. (So, getting a right answer by sheer coincidence when the solution is wrong is not acceptable.)
- The solution to the problem must be complete, meaning that a member of the standard MTH 325 audience (see above) can trace your solution from beginning to end and be persuaded that your answer is correct without having to reconstruct or guess at significant portions of your thinking. The solution in other words should have no significant gaps. (Mathematical steps that would fall under the heading of prerequisite knowledge, like using the FOIL method or doing basic arithmetic, can be safely skipped.)
- The solution must be clear in the sense that it is well-organized, it keeps the reader informed as to what is going on, and the logic of the solution is easy to follow.
- Additionally, your solution should abide by the following format specifications:
- Mathematical notation must be written correctly and used properly. In particular, you may not use the equals sign (=) in any manner except to connect two expressions that are known to be equal.
- If you give a variable name to a quantity, you must do this in a clear way and not change the variable name in the solution.
- Any writing that you do must abide by basic rules of English usage, namely: no misspelled words, no incomplete sentences, subjects and verbs agree, and punctuation is used correctly.
- All sentences and mathematical expressions are semantically correct. That is, sentences and statements must not only be grammatically well-formed but must also make sense. For example, the sentence "The set U is less than the set V" is syntactically correct (no grammatical errors) but not semantically correct because the term "less than" doesn't make sense when applied to sets. Here are a few more syntactically correct but semantically incorrect sentences:
- The number 5 is commutative.
- The number 17 is relatively prime.
- We now square both sides of the equation x+5.
Learning Modules involve solving problems, like you will do on CORE-M problems, but with significantly more high-level work involved. All Learning Modules must abide by the following basic formatting rules:
- The submission must be typed up using LaTeX, Microsoft Word, or some other typesetting system capable of rendering mathematical notation. Handwritten work is not accepted.
- The completed submission must be saved as a PDF file type. (If submitting work as a Sage notebook, see "Specifications for computer programs and code".)
- The file name of the submission must be exactly as specified on the Learning Module.
- The submission must include the student's name and section number at the beginning of the work.
- The solutions in the submission must be done in the order they were presented in the Learning Module.
- All mathematical graphical items such as directed graphs must be computer-generated and not hand drawn.
Work on Learning Modules includes not only solving applied mathematical problems but also programming, writing mathematical proofs, and writing responses to questions that are not necessarily mathematical in nature. Below are lists of specifications for each kind of work.
In addition to particular specifications that might be given in the Learning Module itself (for example, a minimum word count), all written work -- including writing that is part of a mathematical calculation or proof as well as writing outside of a mathematical context -- must abide by the following:
- Your writing must be almost entirely free, if not entirely free, of spelling errors.
- Your writing must be almost entirely free, if not entirely free, of the following basic grammatical errors:
- Incomplete sentences
- Subject-verb disagreement
- Misuse of punctuation (periods, commas, apostrophes, etc.)
- Your writing must be clear to a member of the standard audience for MTH 325.
When writing a solution to a mathematical problem, or writing a narrative that contains significant mathematical work in it, your work should abide by the general specifications for writing above and the specifications for mathematical work listed in the section on CORE-M problems above. This applies to all problems that are not proofs or programs; for specifications for proofs and programs, see below.
If you are writing a mathematical proof, your work should meet all the specifications for general writing and all the specifications for mathematical writing, and the following:
- Proofs must be preceded by a carefully worded statement of the proposition being proved.
- Proofs must begin with a statement of your assumptions.
- Each step of a proof must be expicitly justified by references to definitions, previously-proven work (using the Section and Theorem number), or some similar designation. If a step is justified by prerequisite knowledge available to the standard MTH 325 audience (such as using the FOIL method or a law of exponents) then these steps should be shown but do not need to be justified. However you may wish to err on the side of caution if you're not sure if a step is basic enough.
- Proofs must end with a clear statement that the conclusions have been reached and that the proof is over.
For more details on proof specifications, please see Appendix A: Guidelines for Writing Mathematical Proofs from Ted Sundstrom's Mathematical Reasoning: Writing and Proof provided on the Blackboard site. These guidelines are the standard specifications for proof writing used in all proof-based courses at GVSU.
Some Learning Modules involve writing and submitting computer code in the form of user-defined functions written in Sage or single computations done in Sage. Often, these are to be turned in by placing them in a folder in your SageMath Cloud shared MTH 325 project. Computer work must follow these specifications:
- If saving as a file in your SMC account, it must be in the folder and have the filename specified in the Learning Module.
- The Sage notebook must have your name and section number at the top of the notebook in a Markdown cell formatted using headings.
- All computer code must execute with no syntax errors.
- All computer code must produce the correct output.
- All computer code must contain comments (either inline comments or comments preceding the code placed in a Markdown cell) that clearly indicate the item on the Learning Module to which it belongs.