FALL 2004
(Last Mod: 27 November 2010 21:38:38 )
The Panic Page is a place to come to see if the cause of your frustrations have already been hashed through by someone else. This should become the first place you come for assistance as I hope to post the results of conversations and e-mails with students here if I feel that others may benefit. Rest assured, any such post will be completely sanitized of any identifying information.
05 DEC 04 - HW#A - Conflict between structure tag and math.h.
The authors used the name "complex" for their structure tag name. This works as long as you don't need to access any of the functions in the <math.h> library, which has its own structure declaration that uses that same tag name. To get around this conflict, simply change the tag name to something other than "complex" - such as "Complex".
05 DEC 04 - Exam 2 Make-up updated with due date and name.
The original page did not include the due date or the name that was to be used. Everything else is unchanged.
05 DEC 04 - Exam 3 Review webpage problem fixed.
The updated Exam 3 Review failed to post to the website. This problem was just identified and corrected. There will be no questions on the exam regarding dynamic memory allocation and linked lists. Note that the extra credit problem deals with a topic that we have not touched on in class - that's why it is extra credit.
03 DEC 04 - Exam #2 MakeUp assignment available.
The makeup assignment for Exam #2 is available here.
03 DEC 04 - "Working with Structures" Demo Code available.
The code that was in the Power Point slides from class on Thursday has been brought into a program and made available as "pt3d.c" on the Example Code page.
For what it is worth, the typos that were pointed out in class were corrected immediately after class and posted to the website. I also added the remaining utility function, fprintPT3D(), that we wrote in class on the whiteboard. After copying in all of the code from the slides into a .c file the first compile attempt revealed two more typos - the name of one function and failure to change the loop test condition in the fprintPT3D() function from PTS to 3 after copying it from main(). The corrected PPT file has been uploaded to the website. After fixing those, adding a SKIP constant that multiplies the variable theta in main(), and adding the small amount of additional code to main() that opened a text file for writing, the code compiled and ran immediately and generated the proper data for the star on the first attempt. The entire process - from the time I opened the new .c file to the time that the final file was posted on the website - took fifteen minutes. The reason it went that smoothly is because each function was small and simple and had a very well defined task associated with it. As a result, virtually every error was found - by the students - during class on Thursday.
19 NOV 04 - Example Code related to HW#9 available.
The code that was used in class on Thursday and that we will be looking at next Tuesday is available on the Example Code page. The filedump.c program has been there from the beginning and is about halfway up the page. The new additions are at the bottom.
Now that you have had a chance to look for information on WAV files yourselves, here is the site that I found the most useful overall:
http://ccrma.stanford.edu/CCRMA/Courses/422/projects/WaveFormat/
Keep in mind that this is a site put together as part of a student project and it is not without error. The most noticeable ones are:
It indicates that the fields that are text strings are in Big Endian while all of the fields that encode values are in Little Endian. As we have discussed in class, the concept of "endianness" only applies to multi-byte values and strings of ASCII codes are not multi-byte values so they the concept doesn't apply.
A few places are affected by the fact that the student that wrote this didn't quite grasp the concept of bit and byte padding. A given sound sample consumes in integral number of eight-bit bytes. Therefore, if there are twelve bits of data per sample (BitsPerSample is 12), then each sound sample will require two bytes because that is smallest number of bytes that can contain the data. For the most part, any place that he uses the term (BitsPerSample/8) he really should use (ceil(BitsPerSample/8)). Had he recognized this, then he would have answered some of his own questions such as, in the Block Align description, "I wonder what happens when this number isn't an integer?" It won't ever not be an integer.
At the bottom of the page (in the Notes) he states:
Here is what that means: The total number of bytes in the file must be even. If it is not naturally that way (which will usually be the case) then a padding byte that is zero must be tacked onto the end.
09 NOV 04 - No HW this week - read up on WAV files.
There will not be any homework due this week (nothing due on 14 NOV 04). Please read Chapter 9 in the textbook and do a search (for instance, using Google) on the Windows WAVE File format. Try to understand the general idea of what a WAV file is, what type of information is stored in it, and how it is organized. We will be working with this file format extensively over the next couple of weeks.
26 OCT 04 - Error in Class Notes.
An error in the material presented in class a week or two ago has been brought to my attention. The material had to do with the comparisons of the various ways of representing negative numbers. Specifically, the mapping for the negative numbers using two's complement was incorrect. A summary with this information has been added to the reading material.
26 OCT 04 - HW#7 Deadline moved back.
This homework was due on Sunday, 24 OCT 04. The Grace Period has been extended to midnight, Sunday, 31 OCT 04.
17 OCT 04 - HW#6 Deadline moved back due to network difficulties.
The network, particularly the network drive that most student accounts are on, has been experiencing difficulties since Wednesday. I had been under the impression that the problems were fixed on Friday and this impression has been reinforced due to the fact that there have been several students in the lab this weekend working on the homework. But in talking to the lab monitors I have learned that the problems are continuing on an intermittent basis. In light of that, I'll make the due date Tuesday at the start of class - the same time that the written part is due. To dissuade people from skipping class in order to get started on their homework, this will be a hard deadline - no Grace Period. Any homework received after 1915 on Tuesday evening will be rejected.
03 OCT 04 - Place ALL #include statement where they belong.
Several people continue to just throw the various parts of your code wherever they happen to end up when you paste code from a demo program or wherever you got it from. The Source Code Template reserves specific places for specific elements of your code for specific purposes. One of these is the section set aside for #include statements. Unless you have a very good - and documented - reason for placing a #include statement anywhere else in your file, they had ALL better be in that section.
Also, recall that you are supposed to list the items that you are using from each of the standard header files. Most people are ignoring this - and losing points as a result. Why? What is the motivation to just throw those points away?
03 OCT 04 - Don't submit code having more than 75 characters per line.
Several people are still submitting code with lines that go beyond the 75 character limit. STOP!!
Sooner or later your code is going to get routed through an e-mail server that word-wraps long lines for you and the result will be code that won't compile. If and when this happens, your code will be graded as uncompilable code and lose major points accordingly. This has happened every single semester. If you then petition to have your code graded because it compiled on your machine, the response will be that the issue of line lengths was addressed at the beginning of the course, the Style Guidelines are explicit on this point, and more than fair warning was given. The grading decision will therefore stand. This has also been demonstrated every semester.
You have complete and total control over this issue. All you have to do is NOT submit code that has more than 75 characters on a line and you will never be subject to this rule. Check your work!
03 OCT 04 - Compiler Quirk and How to Get Around It
Some people have encountered errors when compiling the demo code from last weeks lecture. The reason is because they have been invoking the C++ compiler and not the C compiler. Upon investigating the problem, it appears there is a quirk in how TurboC/C++ chooses which compiler to invoke.
The underlying problem is that the demo code performs some "pointer abuse" in order to force the memory usage to be what I wanted it to be for the purpose of demonstrating data collision. Hence I assign a value that is a pointer of one type (a char *) to a variable that is a pointer of another type (an int *). The C compiler will permit this but throw a warning about a suspicious pointer conversion. The C++ compiler, on the other hand, requires that pointers agree and hence throws an error. In either case, the warning/message can be suppressed by using a type cast.
If you are getting the error thrown and not the warning, it is because the compiler thinks you are compiling a C++ file and not a C file. It most likely got this idea because you probably used the "New" option from the file menu to create the new file and then pasted code into that file. Apparently, TurboC/C++ selects which compiler to invoke based on the filename when the file is first opened and when you use "New" it opens with a *.cpp extension and so the C++ compiler is selected. This decision apparently remains unchanged even if you use "Save As" to change the name and give it a *.c extension. The solution appears to be save the file as the new name, close it, and then open it again. This appears to select the correct compiler.
30 SEP 04 - HW#5 Tweaks #2
Since we didn't get as far as I was hoping, the only required part of HW#5 is the first part - writing kgets().
Download and play with the code we were working with in class tonight.
HW#6 is delayed until after the Exam.
30 SEP 04 - HW#5 Tweaks
A couple of typos were corrected in the HW#5 Assignment page. Also, the type of the second argument of the kgets() function was changed from int to size_t. The reason is explained in the assignment. Finally, the two functions involving dynamically allocated memory were converted to extra credit.
29 SEP 04 - HW#3 and HW#4 Solutions posted
Homework #3 and Homework #4 solutions are now available on the Homework Links page.
28 SEP 04 - EXAM #1 Date Set and Review Material Available.
The date for Exam #1 has been set for 07 Oct 04 and the Review Material is now posted on the Exam Links page.
23 SEP 04 - HW#4 modified
Homework #4 has been modified to remove the second portion (it will be added to a later assignment). The first portion has been modified to included the specific test function you are to write to test your new PutS() function.
14 SEP 04 - Homework schedule pushed back one week.
It has become clear that a good fraction of the class is struggling with the material we have covered thus for. As this is fundamental material, we will take a week to try to make sure everyone is comfortable with it. To that end, the future homework assignments have been delayed by a week. This has been done by making what was HW#3 into HW#4 and so on. This opens up HW#3 which is now identical to HW#2 - in other words, if you did not get HW#2 finished to the degree you wanted to, you now have the opportunity to do so and submit it as HW#3 (with the filename, e-mail subject line, and header content correct for being HW#3).
HW#2 is now being treated as Extra Credit. Those that DID turn it in on time will receive 50% of a normal HW assignment's grade as extra credit (which equates to 1% added to your final course grade). Those that did not turn it in on time but did turn it in during Grace will receive 40%.
On Thursday we will plan on developing two functions, one that outputs strings to the keyboard and one that outputs numbers in engineering notation with scaled units and a specified number of sig figs. So if we wanted to output 0.0453V to 4 sig figs, it would print "45.30mV".
11 SEP 04 - (Significant) HW#2 Hints.
Really - this is NOT supposed to be a difficult assignment.
You are to write a total of eight functions - four of them print out the contents of integer variables and four of them print out the contents of floating point variables.
The function PutV_i() was developed in class (except
for counting the number of characters printed) and the function
PutV_u() is developed in the course notes (Lesson 3 as the
Put_u() function, again, except for returning the number of
characters printed).
Taking the code directly from Lesson 3, we have as our starting point:
void Put_u(unsigned int n)
{
unsigned int m;
int i;
/* Determine how many digits there are */
for (m = 1; n/m >= 10; m*=10 )
/* EMPTY LOOP */;
/* Print out the digits one-by-one */
do
{
for(i = 0; n >= m; i++ )
n = n - m;
PutC((char)('0' + i));
m = m / 10;
}while ( m >= 1 );
}
What needs to be added in order to count how many characters are output? How many places are there in the function that actually cause characters to be output? How many characters get output each time that place is reached? What would happen if we simply kept track of how many times we reached that place and returned that value a the end?
int PutV_u(unsigned int n)
{
unsigned int m;
int i;
int c;
/* Determine how many digits there are */
for (m = 1; n/m >= 10; m*=10 )
/* EMPTY LOOP */;
/* Print out the digits one-by-one */
c = 0;
do
{
for(i = 0; n >= m; i++ )
n = n - m;
PutC((char)('0' + i));
c++;
m = m / 10;
}while ( m >= 1 );
return c;
}
Once you have the PutV_u() function, consider the following for the PutV_i() function:
int PutV_i(int n)
{
int c; /* # of chars printed */
c = 0;
if ( n < 0 )
{
PutC('-');
c = 1;
c += PutV_u(-n);
}
else
{
c += PutV_u(n);
}
return c;
}
This can be condensed quite a bit:
int PutV_i(int n)
{
if ( n >= 0 ) /* Handle nonnegative values */
return PutV_u(n);
PutC('-');
return 1 + PutV_u(-n);
}
How much different from this can PutV_li() and
PutV_lu() be?
The floating point functions represent only a minor extension beyond the integer functions. Walk through a three or four digit number step-by-step by hand using the logic in PutV_u() and be sure you understand why and how it works. Then ask yourself what you would need to do differently if you wanted to keep printing past the units digit.
To demonstrate that these functions work you are asked to use values that
are "typical" and "extreme". For instance, for the signed integer data type,
how about using 1, 0, and -1 as the "typical" values and the minimum and
maximum values that an int can represent as the extreme
values? So what are the min and max values? As stated in the assignment, these
are available via constants in the file limits.h. What are their names? Look
up "limits.h" in the index of your textbook and you'll find that it says that
file is discussed on page 75 (IIRC). If you look on that page, you'll find
that it mentions limits.h on that page (and hence why the index lists that
page) but that the table of constants is actually on the next page. If you
look at the table, you'll see that the constants INT_MIN and INT_MAX are equal
to the values you are looking for.
So what would you expect to happen if you call the first listed in the homework assignment with:
PutV_i(INT_MIN);
PutV_i(-1);
PutV_i(0);
PutV_i(1);
PutV_i(INT_MAX);
Since this function only prints out the characters that make up the value - and nothing else - you'd expect the numbers to be run together, right? To clearly show which characters are being printed out by each call to the function, let's surround the output with square brackets and let's print each number on a separate line:
PutC('['); PutV_i(INT_MIN); PutC(']');
PutC('\n')
PutC('['); PutV_i(-1); PutC(']');
PutC('\n')
PutC('['); PutV_i(0); PutC(']');
PutC('\n')
PutC('['); PutV_i(1); PutC(']');
PutC('\n')
PutC('['); PutV_i(INT_MAX); PutC(']');
PutC('\n');
We can't claim to have adequately tested the function unless we show that the return value is also correct for each of the above cases. So let's add the code to print out the number of characters printed in parentheses after the number itself. To do this, we need to store the return value of the function call until it's time to use it a bit later. Picking just one particular example, say printing out -1, we might then encode this as:
PutC('['); d = PutV_i(-1); PutC(']'); /* Print out -1 */
PutC('('); PutV_i(d); PutC(')'); /* Print the number of characters output */
PutC('\n');
As for printing out the binary representations, you already have a function
that does that for you - namely the PutIR() function
developed in Lesson 6. To use the function, you need to pass it three
parameters - the address at which the value is stored, the number of bytes in
the value, and an integer that tells the function how you want it to appear on
the screen.
Since the function needs the address where the value is stored, we can't pass it a constant (constants are not objects stored like variables in memory - they are hard coded as part of the instructions in the program). But we can assign them to a variable and pass the address of that variable.
We'll surround the representation with curly braces - this makes each of the three types of output on each line clearly identifiable. For our purposes, the display method that makes the most sense is to print them out in forward order, in binary, with a space between the bytes. To avoid having to type/copy that for every call, we can use an object-like macro:
#define FORMAT (IR_FWD + IR_SPACED + IR_BIN)
...
int d, v;
...
v = -1;
PutC('['); d = PutV_i(v); PutC(']'); /* Print out v */
PutC('('); PutV_i(d); PutC(')'); /* Print # of characters */
PutC('{'); PutIR(&v, sizeof(v), FORMAT); PutC('}'); /* Print Int Rep */
PutC('\n');
To print other values, we now merely need to copy the above block of code and change the constant in the first line:
#define LIKETHIS (IR_FWD + IR_SPACED + IR_BIN)
...
int d, v;
...
v = INT_MIN; /* Extreme Negative Value */
PutC('['); d = PutV_i(v); PutC(']'); /* Print out v */
PutC('('); PutV_i(d); PutC(')'); /* Print # of characters */
PutC('{'); PutIR(&v, sizeof(v), LIKETHIS); PutC('}'); /* Print Int Rep */
PutC('\n');
v = -1; /* Typical Negative Value */
PutC('['); d = PutV_i(v); PutC(']'); /* Print out v */
PutC('('); PutV_i(d); PutC(')'); /* Print # of characters */
PutC('{'); PutIR(&v, sizeof(v), LIKETHIS); PutC('}'); /* Print Int Rep */
PutC('\n');
v = 0; /* The one value that is neither negative nor positive */
PutC('['); d = PutV_i(v); PutC(']'); /* Print out v */
PutC('('); PutV_i(d); PutC(')'); /* Print # of characters */
PutC('{'); PutIR(&v, sizeof(v), LIKETHIS); PutC('}'); /* Print Int Rep */
PutC('\n');
v = 1; /* Typical Positive Value */
PutC('['); d = PutV_i(v); PutC(']'); /* Print out v */
PutC('('); PutV_i(d); PutC(')'); /* Print # of characters */
PutC('{'); PutIR(&v, sizeof(v), LIKETHIS); PutC('}'); /* Print Int Rep */
PutC('\n');
v = INT_MAX; /* Extreme Positive Value */
PutC('['); d = PutV_i(v); PutC(']'); /* Print out v */
PutC('('); PutV_i(d); PutC(')'); /* Print # of characters */
PutC('{'); PutIR(&v, sizeof(v), LIKETHIS); PutC('}'); /* Print Int Rep */
PutC('\n');
11 SEP 04 - HW#3 modified.
Homework #3 has been modified slightly - instead of writing a function that gets a string from the keyboard, you only have to write a function the puts a string to the screen which is noticeably easier. The function that gets a string from the keyboard is now part of HW#4.
Once you write the PutS() function your ability to display meaningful output will go up considerably - you are expected to take advantage of this new ability to start making your screen output meaningful to the User.
30 AUG 04 - HW#0 submissions show need to pay attention to detail.
As can be seen by looking at the submission report, a significant fraction of the class had difficulty following the file naming conventions - and even a number of people that understood the convention well enough to correctly indicate the file name in the e-mail subject line didn't attach files that had the name that they claimed they had.
These conventions are not just so that the Grader can be nitpicky. For instance, the software that parses the e-mail subject line finds the course number by looking for a string of text surrounded by square brackets. It then looks finds the file name by looking for a string with a space on each side of it. Finally it finds the name by looking for a string surrounded by parentheses. After it has made the first level of parsing it then proceeds to parse the filename - assuming it was able to identify one - by pulling the assignment number, the section, the programmer code, the revision number, and the file type from that string of text. It needs to be able to extract this information otherwise it has no way of determining if you submitted your assignment and, if it can't determine that you submitted your assignment, it doesn't generate a grade report for you. The only files that get graded are the files that have grade reports in the queue.