(Last Mod: 27 November 2010 21:38:41 )

(new material in red)

ECE-1021 Home











The final course grades will be curved.


The maximum score at which a given grade break will be placed is as follows:

Grade Max
A 93
A- 90
B+ 87
B 83
B- 80
C+ 77
C 73
C- 70
D+ 67
D 63
D- 60

The actual grade breaks are generally a few points below those shown.


The following is the general schedule for homework assignments - it may be modified for any number of reasons including adjustments for class cancellation (weather, instructor illness, etc) or to match the pace at which material is being covered.

Note that although the end-of-section exercises are not assigned in the sense of being required to be turned in, it is HIGHLY advisable that you work through the majority of them.

Grading Criteria  

Each Homework Assignment is worth 100 points. These points will be allocated roughly evenly between the correctness of your submission compared to the problem statement, the quality of the algorithm used, and the quality of the submitted code. 

If your code does not compile, it will receive at most a grade of 50. While this sounds harsh, consider how much you would be willing to pay the person that worked on your car if your car wouldn't even start when they claimed they were finished. Many CS classes will not give any credit at all for code that won't compile.

In general, the grader's test data will consist of three types of data - typical data, data intended to test the limits and/or subtle points of the algorithm, and bad data. For instance, if your program is supposed to calculate the counter-clockwise angle from the positive x-axis of a given point, the grader's data may consist of a point in the first quadrant, a point in the third quadrant, and the origin.

Remember that the quality of the algorithm and quality of the code must be based on the submitted code itself. 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. Code that is well organized and documented will naturally receive a significantly better grade than code that is poorly organized and documented, even if the underlying algorithms are virtually identical. 

In addition to the criteria shown above, your submitted work is expected to adhere to the Programming Style Standards for this course. Deviations from them will incur penalty points. As a rule, each section in the standards that is violated will receive somewhere between one and five penalty points depending on severity, flagrancy, and what point in the semester the course is at.

Also keep in mind that the above grading criteria apply to submissions where it is apparent that an honest effort has been made to satisfy the program requirements. Turning in a program that prints "Hello World" each time thinking that it is automatically worth 50% will prove to be a bitter disappointment when the grader rejects the submission entirely and assigns a grade of zero. The grader has the authority, at their discretion, to estimate the fraction of a problem that was honestly attempted and to multiply the final grade by that fraction. This usually is not done because the penalties such a submission inevitably accrues (see The Proper Care and Feeding of Homework Graders) are usually sufficient.

File Submission Method and Deadline

Files are due at midnight on the due date. A Grace Period lasting until midnight the following day will be allowed. Files received after the end of the Grace Period will not be accepted for grading.

Homework is to be submitted by e-mailing the files, as attachments, to the course grader at . Only one attachment per e-mail - the extractor program will retrieve only one attachment per e-mail. The Subject line for the e-mail consists of three parts - the Course ID, the File ID, and the Student ID - as follows:

[ECE1021] filename (LASTNAME, Firstname)

So something like:

[ECE1021] 3_2JOHP2.c (JOHNSEN, Peter)

Please note the format carefully:

It may sound nitpicky, but close adherence to this format considerably improves the grader's efficiency. For instance, the Course ID is used by the e-mail server to generate an autoresponse (if the e-mail also has an attachment). The rest of the file name is used by a submission sorting program to parse the e-mail attachments and prepare initial grade reports. If that isn't motive enough, then the fact that you will lose points for failing to adhere strictly to this format should be.

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. Note that the copy sent to the instructor IS NOT an alternative method of submitting your files - it is "a back-up against transmission failures to the course grader". In order for the copy sent to the instructor to serve as a back-up, it must be the same e-mail that was sent to the Grader. In other words, don't e-mail the file to the grader and then turn around and e-mail the same file to the instructor. The file must be sent to the Grader and the Instructor at the same time - this documents the attempt to send the file to the grader since the grader will be shown as a recipient in the e-mail header received by the instructor. Unless the Grader is shown as a recipient, the file received by the instructor will not be accepted for grading.

Unless otherwise specified, the pseudocode is to be in an ASCII text file with a *.txt extension. When allowed, flowcharts are to be transmitted as a jpeg image with a *.jpg extension. Flowcharts are to be drawn using some type of a computer graphics package - they are not to be hand drawn and scanned in.

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 (not recommended), 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 at midnight on the due date. The purpose of the Grace Period is not to give you another day to work on your code - or, for some, to finally get around to starting on your code - but to give plenty of time for the e-mail to reach the school's servers and to give you time to identify and correct submission problems (such as Internet connection or e-mail server problems) with sufficient time to 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.

Notice that files must be "received", not "sent", by the deadline. It is a simple matter to make an e-mail appear to have been sent prior to the time at which it was actually sent since this is controlled by the sending computer's clock. Therefore, what matters is the time that they were "received" by the grader's/instructor's respective e-mail servers. Keep in mind that e-mail transmission is not instantaneous so allow for this and don't hit "send" one minute prior to the deadline. 

You may submit your files more than once - the submission with the highest revision number will be the only one 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 - but keep in mind that the revision number is subtracted from the final grade.

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. Please do not inundate the grader or the instructor with e-mails asking if your file was received.

File Naming Conventions

These are described in detail in the Style Standards document for this course.

Pseudo Code Requirements

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.

Source Code Requirements

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. 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 the Borland Extensions and that will be the test used to determine if a particular source code file is valid.

Documenting Deviations from Pseudocode

Your source code is to match the pseudocode that was submitted for grading. Any deviations from it are to be documented in the submitted source code. Note the use of the phrase "submitted pseudocode" - it is not acceptable to revise your pseudocode so that it matches your final source code and then send that along with your source code. Your opportunity to do that expires at the pseudocode submission deadline. 

You do not need to be very extensive in these comments - they should primarily serve as a head's up that a deviation exists with a short (one line or so) description of why a deviation is necessary or beneficial. A side effect is that the need to put them there is a bit of a hassle and the more carefully thought out your submitted pseudocode is the fewer deviations there will be in the source code and the less time you will need to spend documenting those deviations. 

If you do not turn in the pseudocode by the deadline, then you have another issue to contend with - namely that if you do not document how your source code deviates from your pseudocode, you lose another ten points off the homework grade. Since you have no pseudocode, this means that your source code deviates in every way from it.

File Header Format

These are described in detail in the Style Standards document for this course.

In your source code files the described header format is expected to be followed EXACTLY otherwise points WILL be deducted. This is for a few reasons:

First off, the statements are actually not comments (except for the top and bottom horizontal line of equal signs). They are actually "nonparamaterized macros" that are used by the function PrintHeader() that is provided for you to print out this header information at the start of your program. Do not worry about what these lines do or how PrintHeader() works - we will cover that in due course. At this point it is only necessary to understand that any deviation from this format is highly likely to result in nonfunctional code.

Second, when you have to sift through a hundred or so files and/or printouts, having a rigid format makes that process much easier. Please refer to the section on The Proper Care and Feeding of Homework Graders to see why this is important to you.

Third, 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 specific information, and then simply copy and tweak for each succeeding file submission.

The Proper Care and Feeding of Homework Graders

Your homework is going to be graded by a Homework Grader (who may, depending on the enrollment numbers, be the Course Instructor). 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 frequently 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 many cases.

Keep in mind that the grader has a limited amount of time in which to grade your homework and grading programs is an extremely time consuming process. It typically takes between a half and hour and an hour to grade a single program submission. Since they are being paid to do so, a grader has a strictly limited number of hours they are allowed to spend on grading and, if the instructor is doing the grading, they are not even being paid to do so. In either case, the person doing the grading is not going to look favorably on submissions that are a waste of their time.

To be clear on this last point, any submission that is an honest attempt and represents a significant effort to solve the assigned problem does not fall into this category. But code that is turned in "just to turn something in" even if it bears no resemblance to the assigned problem or that represents virtually no effort are examples that do. For instance, if you are given code to serve as a starting point and that is all you turn in, expect to receive a zero. If you are told to modify the previous assignment's code to add new features and you only turn in a copy of the previous assignment's code, expect to receive a zero.

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 may be announced or unannounced and may be given at any time during the class. 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 unless it is distributed with the quiz. You may use a calculator if you desire, but work must be shown to receive credit.

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. 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 rely heavily on partial credit. Keep in mind that any given quiz only represents one percent 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.

If fewer than twenty quizzes are given, you will receive maximum credit for the remaining quizzes. If more than twenty quizzes are given, your highest twenty scores will be used for your quiz grade and any remaining scores will be considered extra credit.


As with quizzes, you may only take exams in your assigned section and they may not be made up if missed. There will be three exams in this course. All of the exams are cumulative but will emphasize the material not covered on previous exams.

The exam will normally consist of four parts:

A review sheet will be made available approximately two weeks prior to each exam. At least 50% of the points on the exam will come from the review sheet either verbatim or with only minor modifications (such as using different values).

Don't let this lull you into a sense of complacency. The philosophy behind this approach is that it motivates you to seriously focus on all of the material covered by the review exercises and if you are adequately prepared to answer any of those items then there is a strong likelihood that you have a solid grasp of the concepts covered by that material. This is the same approach that the Federal Aviation Administration takes with all of its pilot written exams (from private pilot to airline transport pilot). But this philosophy would be completely invalid if all you had to do was memorize the solutions to a bunch of problems. For this approach to work, the amount of review material must be sufficiently extensive so that rote memorization of the answers is not practical and that you will have to grasp how to solve the problem when you see it. For example, the Private Pilot written exam consists of just 60 multiple choice questions and you have prior access to every single question, verbatim, that they can choose from - all 1000+ of them.

If you think you will start going through the material the night before the exam, you will be in for a very unpleasant surprise. Also, another thing to keep in mind is that the type of question that is reasonable to ask if you have never seen it before is very different from the type of question that it is reasonable to ask if you have had access to it for weeks. It may take you a considerable amount of time to figure out how to solve it the first time you attempt to do so - and if the first time you attempt to do so is when you sit down to take the exam then that is a choice you made. 

Exam Review Sheets

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 and that are typical of what you can expect to see on the Exams.

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.

Exam Reference Sheets  

Reference information will be provided on the course website and this same information will be provided, in largely the same format, as part of the exam packet. This Reference Sheet consists of the following items:

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. 

Materials that May be Brought to the Exam

You are expected to bring appropriate writing utensils (pen, pencil/eraser) and are allowed to bring a scientific calculator for use in performing basic computations during the exam. Even if your calculator can perform some of the tasks, such as number base conversion, you are not permitted to use those features during the exam. To that end, you are required to show your work on the exam to a degree sufficient to demonstrate that you understand the principles and methods involved in working the problems.


The extra credit described in this section does not include the the extra credit problem that appears on each exam. Credit for that problem is incorporated directly into the exam grade.

Opportunities may be offered throughout the course to earn extra credit. Typically this will be in the form of optional programs to be turned in as part of your normal homework assignments.

The final homework assignment will be treated as extra credit.

The combined total of all the extra credit problems will be added to your final course grade after the grade breaks have been established. A minimum of 3pts of extra credit will be available.

Coupled with the extra credit problems on the exams, this means that effectively a minimum of 8pts of extra credit is available in the course.


Preliminary Final 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 instructor(s) after all grading is complete. This will be the your final course grade unless you fall into one of the following two special categories. 

Safe Harbor

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 two hour long Final Exam can truly be comprehensive and this course doesn't really have a "final" exam since the Final Exam focuses on the latter material in the course. Furthermore, it is unreasonable to ignore your performance in the rest of the course, particularly if your relative performance indicates that you were merely 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 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: Your Course Grade will be no lower than twenty points below your Final Exam Grade. This means that if you get an 95 on the Final Exam, that your grade in the course will be no lower than the letter grade assigned to an overall course grade of 75.

Deep Water

The concept of Safe Harbor has a counterpart. If, on the final day of the course, you cannot demonstrate some minimum level of competence with the material in the course, then you do not deserve a passing grade regardless of your prior marks. However, the same caveats that applied above apply here. It might be reasonable to place an upper limit on the course grade you can receive based on your performance on the Final Exam. However, instead of taking this approach, you are simply held to the following requirement: In order to receive a passing grade in this course, you must receive at least the minimum passing score for the Final Exam. For the purposes of this rule, the minimum passing score for the Final Exam will be determined by taking the overall course grade that corresponds to the Pass/Fail point and subtracting ten points. Typically this point is in the mid 50's so you can expect the minimum passing score for the Final Exam to be somewhere in the mid 40's.

Grades That Are Close To The Final Grade Breaks

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 assignments and this brought you up to a point just short of the grade break, then your actual performance was sufficiently further away from the grade break and 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.