(Last Mod: 04 November 2010 18:09:35 )
(new material in red)
Each Homework Assignment is worth 100 points broken out as follows:
If your code does not compile and run, you will automatically lose the 10 pts associated with generating the correct results for the grader's test data. However, the 20 pts for completeness is independent of this and you may still receive some, most, or even all of these points if the grader can determine from the code itself that you have addressed all of the elements of the assignment satisfactorily. But the grader is NOT expected to spend a lot of time figuring our what your code does or what you wanted it to do - it is your responsibility to adequately organize and document your code to enable the grader to quickly see what you are doing and whether it is a viable approach.
Homework is to be submitted by e-mailing the files to the course grader at ece1011@eas.uccs.edu . The Subject line for the e-mail is to be as follows:
filename (LASTNAME, Firstname)
So something like:
s21_johp.c (JOHNSEN, Peter)
Take a CLOSE look at the above example. Your e-mail subject line is to follow this convention. Period. If it does not then you will lose points. Period.
It is a good idea to cc your instructor a copy of your submission as a back-up against transmission failures to the course grader.
The Pseudo Code can either be text pseudo code or a flowchart. Pseudo Code and Flowcharts must either be ASCII text files or in a format that is readable by a standard installation of Microsoft Word97 or Microsoft Internet Explorer 4.0.
The Source Code must be in the form of an ASCII text file with a *.c extension. If you choose to write your code using a word processor, it is your responsibility to save the file as an ASCII text file that the compiler can read. The grader will not do this for you.
Files are due no later than the beginning of class on the day they are due but a Grace Period lasting until midnight on that day will be allowed and files will be accepted until that time without penalty. The purpose of the Grace Period is not to give you a few more hours to work on your code but to give you time to identify and correct submission problems (such as Internet connection or e-mail server problems) with sufficient time to notify your instructor and work through the problem during the Grace Period. Late submissions will not be accepted after the end of the Grade Period and will receive no credit unless the problem is a server problem at UCCS.
You may submit your files more than once - only the last submission will be graded. This means that it is a VERY good idea to submit SOMETHING prior to the official deadline and then if you make some changes later you can resubmit prior to midnight. That way if there is a submission problem you have the earlier one as a fallback.
Furthermore, sometimes (with absolutely no guarantees) the grader is able to take an initial look at the files that are submitted and, if a problem is spotted, can send you an e-mail and let you know that a problem exists. Again, there is no guarantee that this will happen and it is ultimately your responsibility to submit valid and complete files for grading.
When you submit your file, you should receive an autoresponse from the e-mail system shortly thereafter, but we have had problems with the autoresponder in the past.
Examples
James Montego in section 3 turns in the pseudo code for assignment 5 in a Word document. The filename that should be used is p53_monj.doc
Cheryl Jamison from section 1 submits her source code for Assignment 3 as s31_jamc.c
Carlos Ortiz, an instructor, provides a reference solution program for Homework #2 - it would be called s20_ortc.c
Ideally, the pseudo-code or flowchart for a program should be language independent and sufficiently complete such that the person developing the conceptual solution, who may have little if any programming background, can turn the material over to a programmer who could, in turn, decide what programming language to use and proceed to implement the code without even understanding any of the conceptual goals behind the code being written. For instance, I should be able to give you a flowchart for a function that accepts one value and that then uses that value to produce and return another value. If I have done my job adequately, you should be able to write the function to accomplish this task in any language you are familiar and comfortable with without ever knowing or caring that the function is actually implementing a Bessel Function of Order Zero using truncated Chebyshev polynomials.
In the "real world" pseudo code is used in a variety of ways. Sometimes it is used precisely as described above. Flowcharts also commonly serve as formal documentation for the high level structure of programs and as such generally offer very little detail but, instead, illustrate the overall flow of the program. But from a code development point of view, pseudo-code and flowcharts are generally very informal and incomplete - their purpose is to guide the programmer's thoughts just far enough to enable them to proceed with the coding directly. This is particularly the case when the person writing the pseudo-code and the person writing the source code are one and the same. It is not uncommon to see a flow chart that is very chaotic in that one section has virtually no detail - because it is addressing something the programmer is comfortable with and needs very little guidance on - while other parts are documented in excruciating detail because they deal with something that the programmer is unfamiliar with or having a difficult time getting correct.
Just like in the "real world", the pseudo-code guidelines in this course reflect the purposes of the pseudo-code being submitted. In addition to guiding your code development efforts, the pseudo-code that is submitted must serve to satisfy the grader that you have an adequate understanding of the problem being solved and have a viable solution approach. Keep in mind that the grader's sole insight into whether you know how to perform a particular task is what you have presented the grader with in your pseudo-code. A useful guideline for how detailed your pseudo-code should be is that it should be reasonable for you to hand it to another student in the course who is about average in their performance and who has been keeping up with the material to date (but no further) and expect them to be able to implement the code with little or no difficulty.
Imbedded in this guideline are a few subtleties. As we reach new material, your pseudo-code should be more detailed with regards to that material than it needs to be when dealing with material from considerably earlier in the course. It will be understood that your programming skills are improving and that your pseudo-code and flowcharts don't need to be as detailed about material that you should be familiar with. However, if your source code demonstrates that you are not yet adequately comfortable and proficient with a particular topic, don't be surprised to lose points for inadequately detailed pseudo-code.
As mentioned previously, pseudo-code is ideally language independent, however the reality is that all of the pseudo-code your write in this course will be used to implement source code in a specific programming language, namely C. It is therefore permissible to use C statements and constructs in your pseudo-code and flowcharts. By similar reasoning, it is NOT permissible to use statements and constructs from Matlab, Basic, Java, or any other language you might be familiar with. This is not to say that you can't use these in pseudo-code or flowcharts that you are using strictly for yourself (how would we know, anyway?) but only that the pseudo-code you submit for grading must be free of them.
The only source code file that you need to turn is the *.c file. Your compiler will generate many other files plus a final executable with a *.exe extension. We neither need nor want these files submitted to the grader. Your code is to be ANSI C compliant - and if you follow all of the guidelines covered in the book and in class you shouldn't have any problem with this. The official compiler for this course is Borland Turbo C/C++ v4.5. You may use any C compiler you choose, as might the grader. But the code you turn in must compile and run on the machines in Room 233 using Borland Turbo C configured for ANSI-C and that will be the test used to determine if a particular source code file is valid.
Because of the volume of students in the course and the fact that the e-mail addresses used by students vary from assignment to assignment, a reliable means of determining what e-mails and what files are from which student is critical. The file naming conventions go a long way toward dealing with this issue, but they are neither foolproof nor particularly user friendly - their primary purpose is to minimize the likelihood that one person's file will inadvertently overwrite another person's file. Furthermore, when your file is printed out by the grader, the only means we will have of knowing who's we have is what is in the file itself.
Therefore the following header information is required to be at the top of every document you submit. As much as possible, you are expected to use this format. In the case of your pseudo code, you may need to adapt this format to match the capabilities and limitations of the software you are using to generate the pseudo code and/or flowchart.
/*****************************************************************************/
/* ECE-1011 Summer 2003 */
/* Section:......... 1 */
/* Assignment:...... 2 */
/* Programmer:...... JONES, Samuel K. */
/* File Contents:... SOURCE CODE */
/* Filename:........ s21_jons.c */
/* Due Date:........ 18 JUN 03 */
/* E-mail Address:.. sjones@someplace.com */
/*****************************************************************************/
Take a CLOSE look at the above example. Your file header is to follow this convention. Period. If it does not then you will lose points. Period.
Please use the format exactly as shown above for your source code files. This is for a couple of reasons. First off, when you have to sift through a hundred or so files and/or printouts, having a rigid format makes that process much easier. Second off, there is the possibility that a program might be used to read these files and collect information from them out of the header, so it is very important that the format be followed precisely. This shouldn't be difficult since you can copy it from above, paste it into a text file, modify it for your needs, and then simply copy and tweak for each succeeding submission.
Detailed Instructions:
Programmer name: Last name in all capital letters, followed by the first name (middle initial or name is optional). Please use the name that you are registered under since, when all is said and done, your grades have to be transferred to grade sheets provided by the school.
File Contents: This should be "SOURCE CODE" or "PSEUDO CODE" in all caps.
Filename: The name of the file, including extension, all in lower case.
Due Date: Please use the DD MMM YY format shown above.
E-mail Address: This is the e-mail address that you would like questions or comments concerning this submission to be sent to.
You should have two #define constants in every program - one called VERSION and the other called REVISION. The VERSION number is the homework assignment number. The REVISION number is up to you, but should be a number that increases as you make significant changes to your program. The important thing is that every file you submit to the grader should have a different REVISION value and the latest file - the one you want your grade based on - should have the highest REVISION value.
Your program should print out the VERSION and REVISION numbers at the beginning of each program. Below are example directives and statements accomplish these tasks:
#define VERSION (1)
#define REVISION (2)
printf("Program version: %i.%i\n", VERSION, REVISION);
Your homework is going to be graded by a Homework Grader. It is their job to evaluate what you have presented - not try to figure out what you meant to present. They are your customer - in a very real sense. They are going to pay you with a grade based on the quality of the product you deliver to them. That's how it works in the "real world." If it is readable, complete and correct, you will get paid handsomely. If it is poorly organized, sloppy and difficult to follow, you will not get paid nearly as much - even if the final result is equally correct. If you don't deliver, you don't get paid. Likewise, if your final result is not correct, but your work is well presented, you will get paid for those portions you did deliver (a.k.a., partial credit). Again, believe it or not, that's the way it is in the real world - your customer is the one that ultimately decides how much value your product has and it is not all or nothing in most cases.
Consider a customer that approaches a company to develop a laptop-based GPS navigation system for cars. If the company delivers a solution that works, but it is a black box (no documentation or description of the internal workings) and requires that the user reinstall the operating system every time the street database is updated, then that system is likely to have very little value. On the other hand, another company might have encountered hurdles that it couldn't overcome and delivered nothing more than a bunch of hardware and software modules for various portions of the project. If those modules are well documented such that the customer can take them to another company having the expertise to bring them all together, they may well be willing to pay the majority of the original contract price to the first company in order to get those modules - because even though they didn't get a "correct answer", what they did was on the right track and well presented and therefore has significant value.
Bottom line: Be kind to your grader. Make their life easy. Make it easy to follow your work, particularly your line of reasoning and your approach. Make it easy to see what your code is doing and why.
Quizzes will normally be given at the beginning of class on the second meeting of the week but, at the instructor's discretion, may be given at any time during that meeting and may even be postponed to the next meeting. You may only take quizzes in your assigned section and they may not be made up if missed. No reference material of any kind will be allowed however you may use a calculator if you desire.
Generally speaking, the first question will be focus on the material covered during the prior week, the second question will be from one of that week's reading assignments and the third problem will deal with that week's homework assignment.
The quizzes serve two primary purposes. First, they strongly encourage you to keep up with the course and not put studying and working on the homework off until the night before it is due. Second, they serve to identify weaknesses in your understanding of the material so that you can more reasonably decide how to guide your own study efforts.
Quiz grading standards are somewhat coarse. You will receive two points merely for turning in the quiz as a means of giving credit for class attendance. Most of the quiz questions themselves are all-or-nothing with little, if any, room for partial credit. This is in sharp contrast to the Exams that will rely heavily on partial credit. Keep in mind that any given quiz only represents about 1% of your final course grade. Use it for what it was meant for - an indicator of topics that you might need to study more carefully.
The total quiz grade that you will receive will be computed as follows: There will be N quizzes given (N is scheduled to 8). The lowest quiz grade will be dropped. This will leave N-1 quizzes. This will be turned into a total of 10 quiz grades by replicating the highest (11-N) quiz grades that you have received. In other words, you will receive double credit for your highest quiz scores. For example, if we had to cancel a quiz for some reason and your quiz scores were {10, 8, 6, 5, 4, 2, 0} then the 0 would be dropped and, since only six scores remain, the highest four scores would be duplicated leaving you with {10, 10, 8, 8, 6, 6, 5, 5, 4, 2}. The purpose to this approach is to recognize that everyone is going to have an off day from time to time - you might be distracted, you might not have emphasized the right material when studying, or might be under pressure to study for other courses. This approach de-emphasizes a few poor performances, softens the impact of the all-or-nothing grading, and encourages you to continue putting effort into all of the quizzes since your best performances will be given double weight at the end.
Prior to each exam, a Review Sheet will be posted on the Web Site. This Review Sheet will consist of numerous problems that cover the full range of material covered in the course. It is guaranteed that at least one-fourth of the points on the exam will be taken from the review sheet (or textbook problems cited on the Review Sheet) verbatim. Additional exam problems are likely to be slight modifications to Review Sheet problems.
Basic philosophy: You learn to program by writing programs. There aren't any shortcuts. In an introductory course such as this, how much you learn and how well you learn it are primarily related to the sheer volume of code that you actually write, run and debug. The level of complexity is largely irrelevant provided the code reflects the topics being covered. The amount of coding experience you will get from the homework problems will, unfortunately, be too limited for most of you to become proficient at writing code at the level that is expected in this course.
As a result, most of you need the opportunity to write additional code to get the necessary practice. But since different students learn at different paces, it is unreasonable to demand excessive coding from someone to whom C programming comes naturally (and, yes, such people exist). The Review Sheets permit a means of self-guided supplemental work. You get to decide which, if any, of the problems you work and to what degree you work them. Be forewarned, however, that some of the problems are not trivial and might require quite a bit of time to work them through the first time you see them. However, if the first time that you see them is when you sit down to take the exam, you have only yourself to blame.
A pre-prepared Reference Sheet will be provided on the course website along with the Review Sheet. You may print this out and bring it to the Exam with you. This Reference Sheet will primarily consist of function prototypes for the various standard library functions that you might need on the exam. If, during the exam, you feel that you need a function not on the sheet merely ask the proctor and the prototype for the function will be written on the board. The sheet will also contain other information, such as the Precedence of Operators, that you would normally refer back to your reference books for in the future.
You may not make any notes on the front of the pre-prepared Reference Sheet. However, you are allowed to write anything you desire on the reverse side. This gives you a one-sheet (8.5" x 11") single-sided crib sheet to work with that can contain whatever information you desire up to and including complete solutions for the problems on the Review Sheet. Be advised, this latter approach is not recommended and is likely to backfire. Your goal should be to be able to solve any of the problems on the Review Sheet without any information other than what is on the basic Reference Sheet. If you can do that, you will do fine on the exam.
An optional extra credit homework assignment will be offered at the end of the course. No pseudo code needs to be submitted for this assignment. The grading criteria will be the same as all other homework assignments - with a maximum score of 90pts since the pseudo-code is not turned in. The score on this assignment will be converted to a 3pt extra credit bonus (by dividing the grade by 30) and this score will be added to your final course grade.
Your final course score will be computed according to the weighting at the top of the this page. This will be converted to a letter grade with appropriate '+' and '-' qualifiers as appropriate according to the grading curve determined by the instructors after all grading is complete. This will be the your final course grade unless you fall into one of the following two special categories.
If the Final Exam is truly comprehensive in nature, then in theory your Course Grade should be equal to your Final Exam Grade regardless of your other grades in the course. Unfortunately, no hour-long Final Exam can truly be comprehensive. Furthermore, it is unreasonable to ignore your performance in the rest of the course, particularly if your relative performance merely indicated that you were having an off-day when you took the Final Exam. However, since the entire objective of the course is for you to leave the course with a certain amount of knowledge and skill, the degree to which you can walk in and demonstrate mastery of the material on the last day of the course should be used in your favor to overcome earlier poor performance. To that end, marked improvement in your performance as demonstrated on the Final Exam will be rewarded as follows: If your Final Exam Grade is higher than your Preliminary Final Grade, your Course Grade will be no lower than one full letter grade less than your Final Exam Grade.
Using reasoning similar to the Safe Harbor policy above, students should be able to demonstrate some minimum level of competency on the Final Exam on the last day of the course regardless of their previous grades in the course. To that end, markedly poor performance on the Final Exam will be penalized as follows: Students scoring less than 50% on the Final Exam will receive a grade of F in the course. Keep in mind that fully 25% of the points on the Final Exam will be from questions off the Review Sheets verbatim, therefore this is not an unreasonable expectation.
Grades that are close to the break between the earned grade and the next higher grade will not be given the benefit of the doubt and will receive the earned grade. The reason for this is two-fold. First, if you completed the extra-credit assignment and this brought you up to a point just short of the grade break, then your actual performance was considerably far enough away from the grade break that the extra credit was simply insufficient to overcome the deficit. Second, if you did not complete the extra-credit assignment and your basic grade is just short of the grade break, then the extra-credit would have been sufficient to overcome the deficit but you simply opted not to take the opportunity to claim those points.