I’d gone through the stuff on the post that’s been used as a guide for this exercise, but I still seem to be getting this error:
What should I be looking for in debugging this?
That post by mrgransky is the best one I know to debug this. That type of mistake most commonly means you are handling the stride incorrectly. The stride happens in the input space, not the output space, right? That was covered by that thread.
From the trace you show, we can’t quite tell exactly which of the test cases it is that is failing. If you show the more complete trace, we should be able to see that. One thing I can think of that might not be covered by mrgransky is that you might have interchanged the horizontal and vertical dimensions. Notice that h is for “height” not horizontal, so h is the vertical dimension. w is for width which is the horizontal dimension.
Notice that in some of the test cases, the inputs are not square, meaning the h and w dimensions are different.
Yes, I’ve looked at that post too. I’m not certain how one could confuse the h and w parameters given that the example code already stated the order of the computations of vert_start and vert_end; attempting to “switch” them would’ve resulted in a variable-use-before-definition error anyways.
How would I show a more complete trace? That is the entire trace that came up.
Is there a way I can send you my code?
Sorry, I think you just misinterpreted my suggestion: you switch them by using h in place of w when you do the indexing, meaning use w as the first index and h as the second index.
We can’t share code on a public thread, but I will send you a DM about how to proceed with that.
Ok, to close the loop on the public thread, one of the bugs was more subtle than the information on the mrgransky thread.
The calculation of n_H and n_W had order of operations problems.
The formula is this:
n_{out} = \displaystyle \lfloor \frac {n_{in} + 2p - f}{s} \rfloor + 1
so you have to be careful with your parens there.
The other bug was probably actually triggered by the info on the mrgransky thread, which I had not noticed before: the range on the loop over the channels dimension was wrong and used f as the range. That is actually what it said on that thread, so I have edited it to fix that.
1 Like