Course 4 ,Week 1 Assignement 1 - All test pass but 50/100

[Eran]

There is an issue for a few of us, which all the tests passed, but still got 50/100 score, why is that?

[TMosh]

This is because your code does not work correctly with the tests that the submit grader uses.

[paulinpaloalto]

One common error that the unit tests in the notebook do not catch is ignoring the stride value when you compute vert_start and horiz_start in both conv_forward and pool_forward. There is a test case for pool_forward that uses stride = 2: please study your output values for that case and compare them to the expected values shown. They all need to agree, not just some of them.

[Anurag_Garg]

Hi Mr Paul,

I am taking stride into the account by using it as a jump while calculating width and height within the for loop. Still not able to pass those hidden tests.
My output to the given test also gives the expected result.

Can you please suggest?

Thanks

[paulinpaloalto]

I can’t see anything in the image you posted, but I think what you are describing is a bug. The stride happens in the input space, right? Not in the output space. The range on the for loops is over the output space and you must not skip any positions in the output space. You use the stride within the logic of the loop to compute where the input comes from for the given output position.

[Anurag_Garg]

Sorry that the image quality is not readable. I am posting the image again, maybe it will work.
My Output
myoutput

Expected Output
Expected output

The point I trying to make with the image is that my output for the pool_forward function with stride=2 is the same as expected.

Initially, I was using the stride in the range but later understood the point you are making above, and changed it to input space

vert_start = h if h==0 else h + stride - 1
vert_end = vert_start + f

Only, after making that change got the same output as expected.

I am not sure if this is a bug. but, it is surely something strange, and hence need some more explanation.

Thanks

[paulinpaloalto]

You’ve posted links to the images. I’m not going to click some random link. Why don’t you upload the image to the Discourse post? Just use the little “Up Arrow” tool in the toolbar.

But I think before you do that you need to fix your vert_start calculation. What you show is not correct. It’s actually simpler than that if you think about it. The loops are over the range of h and w. Then on the input side the start position is just h * stride or w * stride, right? Think about it for a sec and that should make sense.

[Anurag_Garg]

Sorry, for the inconvenience. I will try again to upload as an attachment to this reply.

Last time when I tried that button it kept failing. If the attachment also failed maybe it was an internet issue and would work after some time.

Thanks for the hint. I will think and try that.

Thanks

[paulinpaloalto]

That test is not capable of catching your bug because the output dimensions are 2 x 2, meaning that you only take one stride and your code works for that case. It just fails in the general case.

The correct formula is h * stride and you’ve written h + stride - 1. Consider the case that stride = 2. So you can solve the equation:

2h = h + 2 - 1 = h + 1

The (unique) solution is h = 1 of course. So you got either very lucky or very unlucky depending on how you look at it.

[Anurag_Garg]

Thanks for the explanation. Yes, I would say I was lucky. It showed me to be little more extensive with testing process.

Thanks