Np.pad changes all the values to 0

@paulinpaloalto I found a rather peculiar error, this is the hint for zero padding:

a = np.pad(a, ((0,0), (1,1), (0,0), (3,3), (0,0)), mode='constant', constant_values = (0,0))

Then when I implement it, all the tests passed, but the values that are originally non-zero is also set to 0.

This is the output:

x.shape =
 (4, 3, 3, 2)
x_pad.shape =
 (4, 9, 9, 2)
x[1,1] =
 [[ 0.90085595 -0.68372786]
 [-0.12289023 -0.93576943]
 [-0.26788808  0.53035547]]
x_pad[1,1] =
 [[0. 0.]
 [0. 0.]
 [0. 0.]
 [0. 0.]
 [0. 0.]
 [0. 0.]
 [0. 0.]
 [0. 0.]
 [0. 0.]]
x.shape =
 (4, 3, 3, 2)
x_pad.shape =
 (4, 9, 9, 2)
x[1,1] =
 [[ 0.90085595 -0.68372786]
 [-0.12289023 -0.93576943]
 [-0.26788808  0.53035547]]
x_pad[1,1] =
 [[0. 0.]
 [0. 0.]
 [0. 0.]
 [0. 0.]
 [0. 0.]
 [0. 0.]
 [0. 0.]
 [0. 0.]
 [0. 0.]]
[[0. 0. 0. 0. 0. 0. 0. 0. 0.]
 [0. 0. 0. 0. 0. 0. 0. 0. 0.]]
All tests passed!

In addition, when I check the np.pad function, there is no example using the a = np.pad(a, ((0,0), (1,1), (0,0), (3,3), (0,0)), mode='constant', constant_values = (0,0))anymore.

I am completely lost as what to do.

I think you’re drawing incorrect conclusions from that output data. Remember that index [1,1] in the padded version does not address the same data: everything moves because of the padding. The example is showing how to pad on only two dimensions of a 5D array. But we have 4D arrays here and it is only the h and w dimensions that we want to pad, of course. It looks like you must have done that correctly from the output.

@R_Wang , this happened to me recently.

I had an ndarray of shape (30,x, y, z) and the values were between 0 and 1.

I needed to pad that array to make it of shape (50,x, y, z). I applied padding and to my surprise all the values turned to zero!

Then I realized the reason: the padding function needed the type=float32 (or float64). Otherwise it would default to type=int.

May be that’s not your case, but the title seems so close to my case that I thought it would be worth sharing it here.

Thanks,

Juan

Actually, it is a little bit deeper than that. I have been working on the problem for almost a whole day.

Then after running a lot of tests, I might have triggered some changes in the code, which changes a lot of intermediate values.

I have to get a fresh copy, and surprisingly, with just the same code all the tests passed.

All this sounds like maybe some of the problems may be caused by a misunderstanding about how the notebooks actually work. The key thing to realize is that if you type some new code in a function cell and then call the function from the test cell again, that does nothing: it just runs the old code again. You have to actually click “Shift - Enter” on the modified cell to get the new code added to the runtime image. Now that I’ve stated that principle, it’s easy for you to prove to yourself that what I’m saying is correct.

The other thing you can do to make sure that the code you are looking at is actually what you are running is to do these steps:

  1. Kernel → Restart and Clear Output
  2. Save
  3. Cell → Run All

That discards all the generated (interpreted) code and starts everything from scratch based on the actual state of the code.

If you are having problems where you change things and it doesn’t work, you might want to make sure you are “in sync” before you continue with your debugging efforts.

This is exactly the issue and a lesson learned. I have changed the code many times and when I finally get it right, something happened that changes the internal value. Then I spent 9 hours figuring out why. At last minute, I am so frustrated and just get a new copy with the same code. Voila, all tests passed.