How come “AssertionError: Wrong values for dA” involves some shape mistake? I think there are other errors designed to get triggered if a bad shaping was present, which (I think) it is not the case.
PS.: I am having the exact same error, but my results show the following, and I don’t know where my error could be:
hi, i had same problem. i solve it. i think you don’t multiply strides. vert_start and horiz_start is strides * (h or w). i was very tired to realize this. good luck.
Dave - thanks for this suggestion. I actually did account for this (after not properly implementing stride on a previous example) and had the following:
# Find the corners of the current "slice"
% mentor edit: code removed
Turns out when I actually removed stride from the calculations I ended up with the numbers you and others in this thread calculated (db didn’t change).
Do you have any suggestions on where I might be going wrong? Currently going a bit crazy…thanks!
Ah!!! The bug was not in my conv_backward code, but rather in the mishandling of stride in my conv_forward code!!! I guess by sheer luck I caught this.
I guess the tests really need to be augmented to catch further errors in conv_forward, pool_forward, etc especially with regard to stride before they become needles in haystacks for later exercises.
Yes, there is a bug filed with the course staff about the fact that the unit tests for conv_forward and pool_forward do not catch that error. It’s been open for > one month at this point.
Although you could have noticed your code was wrong if you had examined the output of the stride = 2 test case for pool_forward carefully enough. All the values need to agree, not just most of them. It’s just that it doesn’t “throw” when they don’t all match.
Thanks for the quick reply Paul. Yes, totally agree. I think the only difference (in the current iteration of the notebook) is that with the pool_forward exercise the second test cell does help catch stride issues despite not throwing, as you said, which is what helped me catch my bug there. However, I think there was only one conv_forward test cell (w/ stride = 1) which is why I failed to catch my bug there until the conv_backward exercise.
Great! Yes, this assignment is pretty challenging, but it’s fun to really get a detailed view of how convolutions actually work. Pretty soon, we’ll switch to using TensorFlow for all that, but Prof Ng has the philosophy that we really need to have the intuition that comes from understanding how the algorithms actually work. If you just treat everything as a “canned” black box from TF, then you miss out on that level of understanding.