1

FOR CS50 STAFF ACTION:

When I ran check50 against resize, I got a very confusing result. I've seen that others have seen the exact same result. Here's the problem - the output is giving negative results but saying that the output is correct.

In reality, the bitmap is correct in the file, but there are header errors.

STAFF: Can you please correct this issue to indicate the error instead of indicating that it is working 'correctly'? Perhaps you could separate the tests into two phases - one to check the header data and another to validate the bitmap data.

Here is the misleading result:

check50 2014/x/pset4/resize bmp.h resize.c

:) resize.c and bmp.h exist

:) resize.c compiles

:) doesn't resize 1x1-pixel BMP when n is 1

:( resizes 1x1-pixel BMP to 2x2 correctly when n is 2

:( resizes 1x1-pixel BMP to 3x3 correctly when n is 3

:( resizes 1x1-pixel BMP to 4x4 correctly when n is 4

:( resizes 1x1-pixel BMP to 5x5 correctly when n is 5

:( resizes 2x2-pixel BMP to 4x4 correctly when n is 2

As you can see, the last 5 cases say something is wrong, but only tells what is right. My first thought was that there was a bug in CHECK50.

Interestingly, here's a good run. The only difference is the smiley face vs. frown face.

jharvard@appliance (~/Dropbox/pset4/bmp): check50 2014.fall.pset4.resize bmp.h resize.c

:) resize.c and bmp.h exist

:) resize.c compiles

:) doesn't resize 1x1-pixel BMP when n is 1

:) resizes 1x1-pixel BMP to 2x2 correctly when n is 2

:) resizes 1x1-pixel BMP to 3x3 correctly when n is 3

:) resizes 1x1-pixel BMP to 4x4 correctly when n is 4

:) resizes 1x1-pixel BMP to 5x5 correctly when n is 5

:) resizes 2x2-pixel BMP to 4x4 correctly when n is 2

thanks, Cliff

Improve this question
2
  • I got the same result: sandbox.cs50.net/checks/6c02eca1ab1b452e84f592888168ec74 The red items are named "todo". But comparing like this: ./resize 4 small.bmp student.bmp ~cs50/pset4/resize 4 small.bmp staff.bmp ~cs50/pset4/peek student.bmp staff.bmp I get a green result: i.sstatic.net/Kr0Gv.jpg So this is really confusing for me. Is my code correct or not?
    – LirC
    Commented Aug 15, 2016 at 10:13
  • It turned out that my code wasn't correct. I kept iterating too often over the infile's lines because "i < abs(bi.biHeight)". But bi.biHeight was the updated value.
    – LirC
    Commented Aug 15, 2016 at 10:58

4 Answers 4

Reset to default
2

I brought up your concerns to the CS50 Facebook page, and Professor Malan himself replied that a future version will be more explanatory. The release date for this update has not yet been determined.

Improve this answer
1
  • Excellent! Thank you.
    – Cliff B
    Commented Mar 21, 2015 at 1:52
1

Just wanted to add here that it's not always the bitmap header causing this check50 problem:

I also experienced the issue with frown face and text saying it's resizing correct, but in addition my bitmap header was also correct (peeking at it confirmed that).

My code had a different issue: It produced the correctly resized image but continued to write pixels. It wasn't visible with the Image Viewer but I realized my file size displayed in the File Manager was a bit off / too big. I finally could see whats going on with the xxd command and fixed the bug using gdb.

Improve this answer
1

Mine was a header problem as well, though I didn't find the check50 output confusing. This answer helped me a lot, though it's tagged under "pset5", I'm assuming b/c this used to be in pset5 in older versions...

How to Update bfSize in resize?

Improve this answer
0

It is a bit confusing, but once you realize what the lines are saying, and what the smile or frown represents, then it is clearer.

The statements read like a checklist, and the happy face is a green checkmark and the frowny face is a red x. If your resize program correctly does not alter the size of a 1x1 pixel BMP when n is 1 then you get a smile. If your resize program does not correctly resize a 1x1 pixel BMP to a 2x2 pixel BMP when n is 2, you get a frown, and so on.

Improve this answer
2
  • KernelRutgers, you missed the point, so I'll put a big red bullseye on it for you. If your resize program DOES correctly resize a 1x1 pixel BMP to a 2x2 pixel BMP when n is 2, but the header is wrong, you get the following: :( resizes 1x1-pixel BMP to 2x2 correctly when n is 2 What you do NOT get is any clue that the header is wrong. And if you're not paying attention, you might think that all is well because it says that you are correct.
    – Cliff B
    Commented Mar 19, 2015 at 3:21
  • What it SHOULD do is give two separate results, like the following: :) resizes 1x1-pixel BMP to 2x2 correctly when n is 2 :( resizing 1x1-pixel BMP to 2x2 when n is 2 does not produce a correct header Why confuse the issue and give a message that doesn't communicate the problem? This has confused several people and doesn't give any clue about what is wrong. So why not fix it so that the problem is clear?!
    – Cliff B
    Commented Mar 19, 2015 at 3:34

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .