I had a strange situation. I just made the necessary part of the assignment and everything was ok, even the ungraded outputs of stride=2. But to my surprise, I got 75% in the final grading after the submit, failing in one cell.
At this point, I had no clue how to fix the code because everything was ok on the notebook’s test, so I simply made the optional part, resubmit the code, and “voila!!”, got 100%.
Now, I wonder if there is something in the optional part that was needed. But, it must not because it is said to be optional.
I agree with Tom: there is nothing in the optional part that has any effect on the grade. My theory is that you changed some of the actual graded code as well. Or maybe you had changed it already, but had not actually executed the modified cells. Just typing new code in a cell does nothing until you actually click “Shift-Enter” on that cell to get it “recompiled” or do “Kernel Restart” followed by “Cell → Run All”. So WYSINNWYG (What You See Is Not Necessarily What You Get).
Note that there is a well known set of bugs in the unit tests in the notebook for this assignment: they do not fail if you omit the “stride” value in the vertical and horizontal calculations in conv_forward and pool_forward. A bug has been outstanding to the course staff about this for a while now (+2 weeks). (Update: this is an old thread and that bug was fixed sometime in early 2022, meaning that the tests in the notebook will fail if you don’t handle the stride correctly).
Yeah, I always do a kernel restart and check every output before a submit.
And that was my guess too, but I can’t remember what I could have changed of value. The only change that I remember between the submit graded with 75 to the one graded with 100 was the elimination of a “print” statement for debugging purposes. That should not be the reason either.
But, anyway, I just wanted to give a hint. Although, I knew that was a silly one from the start.