A few notes
Previous:
Hashtables
There was a deadline on (re)submissions in late October. That's passed, and these notes are up, which means you can't get full credit,
but definitely submit the assignment if you complete it (which you will need anyway to for the final project).
- A hashtable's array should be declared as object * table. Typically, you want to work with a pointer to an array of pointers to objects, which would mean
object * * table, but the objects in hashtables are not moved around very often so the speed benefit you get by working
with pointers isn't worth the extra memory.
- Hashtables should (almost) always be made resizable. Resize should be done before the table is full, though with
linked-list style you can get away with waiting until it is "full" (no. of currently held objects / total capacity >= 1).
- Resizing means you go through each element (in the linked list case, each element of each non-null list) and rehash,
keeping in mind that the table has a new size. The new size should be a multiple of the previous, say *2.
Map Display
This was due at the end of October, so if you haven't submitted it yet, do so soon! This is also needed for the final assingment
- Nearly everyone successfully read the binary file. Some read the meta data in a more complicated way. If you use C++ style file reading, you can do the following:
...
ifstream fin("binary.dat", ios::in | ios::binary);
short int a, b, c;
string d;
fin >> a >> b >> c >> d; //I know this isn't the file ordering, but you get the point
...
That works here because the beginning of the file is just plain text (byte long characters) that the << and >> operators expect, even though most of the file is formatted for short ints (2 bytes).
You can use sscanf(), strtok(), or a stringstream to read in the meta data easily too.
There are certainly other ways, but why make it harder?
- You should not store the entire coverage.txt file unless the program lets the user load a number of maps. This is a waste of space, and wouldn't work in the case
of a very large file
- You shouldn't create an array of size row*column. This wouldn't work for large maps so it isn't scalable, and since you only need the data points once, it's a waste of memory.
But you also shouldn't read one pixel at time. While this is best on memory, it's very slow (more file accesses)!
The best trade-off is to read in and handle one row at a time, though there are even better ways to read files (using the file's optimal I/O size),
we won't expect you to do that.
- This comment isn't as important as the others but it is more general. The if statement for checking if a map contains the desired coordinates was very long if done all at once.
It makes the code way more clear if you simply make a function that checks this for you. The code is also more clear if you deal only with the absolute values of the change in latitude or change in longitude.
Upcoming:
If you have any questions about the upcoming test (12/1), e-mail us (Paul, Austin; Elliot as a last resort). This is especially true in light of the review session not being as clear and in-depth as we hoped.
If you have questions about the assignments, also e-mail us.
Submit the assignments on time (!). We have been pretty relaxed about deadlines, but there is a fair amount of unsubmitted work left in the class (between late assignments and upcoming ones).
We're also students, and so this time of year is crazy for us too and late assignments only make the workload worse (especially during finals).
We'll set a final deadline for all assignments soon (likely old ones will be due before the final project).
When submitting, let us know what is wrong or what you got stuck on. This makes grading easier and lets us know that you understand your code and tried to work on certain issues.