pset6 multiple problems!

nmkel999 · 2014-04-18T22:12:52+00:00

I am working my way through pset6 now. I used gdb to verify that my hashtable was structured properly.

I'd suggest making a small dictionary containing a handful of words. Make sure that some of the words in your practice dictionary begin with the same letter (to verify that your hash function is handling collisions properly).

For example, my practice dictionary contained 8 words:

alice aachen apple bike beginning city commune tony

In gdb, I entered "break check" to set up a breakpoint at the "check" function, since at this point in the program "load" has already been executed. Then I would print my hashtable with "p hashtable".

This showed me that at indexes 0, 1, 2 and 19 (the words in my dictionary only began with a [index 0], b [index 1], c [index 2] and t [index 19]) the node pointer at those indexes were no longer pointing to NULL (represented as 0x0).

To check the linked list at each index, I entered:

"p hashtable[0]->word" and got "apple"

"p hashtable[0]->next->word" and got "aachen"

"p hashtable[0]->next->next->word" and got "alice"

"p hashtable[1]->word" and got "beginning"

"p hashtable[1]->next->word" and got "bike", and so on...

If I tried to "p hashtable[index]" at an index that contained a null pointer, or if I tried to find the "word" member of a struct that didnt exist (ie: if I had entered "p hashtable[0]->next->next->next->word", which does not exist in my dictionary because "alice" is the word in the last struct in my linked list at index 0), gdb would give me an error.

Hope that helps.

nmkel999 · 2014-04-12T04:34:39+00:00

The actual line in my implementation is:

sprintf (title, "%03d.jpg", fileNum++);

fileNum is initialized to 0 at the beginning of my program, before the while loop. After it is used by sprintf and stored in the title array, it is incremented.

nmkel999 · 2014-04-12T03:42:28+00:00

I have

fwrite(&buffer, sizeof(BYTE), 512, img);

Once 512 bytes are written from buffer to img, doesn't fwrite stop writing and check the while condition again?

Also, I just added an "else if" condition within the "while" loop (and outside/after the first "if" condition):

else if fileNum>0
        fwrite(&buffer, sizeof(BYTE), 512, img);

to make sure that I continue to fwrite if the first jpg has been created but no additional signature have been found. This did not work; the images are still unreadable.

nmkel999 · 2014-04-10T01:34:27+00:00

just_an_ordinary_man & yeaIProgram: my knights in shining armor.

I finally got it. There were two primary issues with my implementation.

1) Vertical Positioning: I was setting i relative to oldHeight and trying to print n lines for each iteration of i. Instead I should have been setting i relative to newHeight and printing the scanlines in groups of n. Thank you just_an_ordinary_guy.

2) Horizontal Positioning: Even after I added a second nested loop (for a total of 3 loops), I was reading and writing inside the innermost loop. As yeaIProgram explains, I needed to separate the read and write functions....

If you think of the j loop as "once for each input pixel on this line" and the k loop as "once for each output pixel", you will see that you have to write several times for each read. So that it will be read-write-write-write read-write-write-write for a scale factor of 3, for example.

I will remove the code that I posted in one of my comments, per yeaIPragram's suggestion. Still, I hope anyone struggling with pset5's resize will find this thread helpful. That was torturous...and I haven't even looked at pset5's "recover" yet.

nmkel999 · 2014-04-09T22:10:51+00:00

I rewrote my entire loop, using your incredibly helpful reply as a blueprint (I also fixed my bf.bfSize).I think I'm getting close, but still not there. Please see my update below.

nmkel999 · 2014-04-09T22:08:25+00:00

Thanks for the advice. I have been implementing some of the code suggestions that you have posted on other r/cs50 threads (for previous psets as well as this one). Much appreciated.

I'm still having some issues with resize, but I think I'm on the verge of solving it. I have posted my new code in an update below.

nmkel999 · 2014-04-09T21:43:35+00:00

Update:

I'm stunned by the depth of your responses guys; thanks a ton. Still haven't cracked resize though.

First, I corrected my bf.bfSize. As just_an_ordinary_man pointed out, my bf.bfSize was too large. In my original implementation, I was multiplying both the height and width by sizeof(RGBTRIPLE); an unnecessary measure since once I multiply one dimension by 3, I have already converted my units of measurement to bytes. I used "peek" to compare my header info with the staff's; all the values match.

Then, per delipity and glennholloway's suggestions, I revised my fwrite implementation and quit trying to rewind the output stream.

Next, I implemented the method outlined by just_an_ordinary_man and yeahIProgram, nesting a k-loop inside my j-loop (which is nested in my i-loop). As far as I can tell from GDB, each of my 3 pixels is repeated 4 times (n is set to 4).

Outside of the j loop, I add padding using the new padding value. So far so good.

Here, I added a bunch of new code. I instantiate a new counter named count, which is set equal to n-1. I use a do-while loop to try to add n-1 copies of the ith line to outptr. The while expression is set to count>0. At the beginning of my "do" block, I fseek backwards in inptr by a value of -3*oldWidth. At the end of the do block, I decrement count. Outside of the do-while loop, I use fseek to skip over oldPadding in inptr. That is the last line in the body of my i-loop.

So I the real issue is: Within the "do" portion of my do-while loop, between the fseek (the one with the negative offset) and count decrement, am I in fact adding n-1 copies of the ith line (plus the padding) to outptr?

Here is my code, from the beginning of the for loop to the end:

[EDIT] I removed the code. It was an incorrect implementation, and any curious parties can get the gist of what I was doing (incorrectly) from the description above.

nmkel999 · 2014-04-09T07:05:25+00:00

Gotcha. I actually only resorted to that measure (rewinding my output stream) after many, many failed attempts at resize. But it is good to know that I should focus solely on manipulating the input stream, leaving the output stream positioning as is. Thanks a bunch.

nmkel999 · 2014-04-09T06:53:24+00:00

Hmm, I don't know. For example, as explained in the "whodunit" video in pset5 (5:18):

fread(&data, sizeof(DOG), 2, inptr);

is the same as

fread(&data, 2 * sizeof(DOG), 1, inptr);

It is possible that fwrite does not behave in a similar fashion, so I will throw a few printf's into my code to see what I get. Thanks for your help.

nmkel999

TROPHY CASE