jiebi/CodeConvo huggingface dataset:
Change:
When I enable the MPS backend on Mac in libtorch, it now crashes with this error when exiting: If I remove: the crash disappears. It only affects exiting/destructing the app. Most likely it is the MPS memory allocator closing down. nightly 1st August 2022. Backtrace (basically it is torch::jit::Module destructor, leading to C10::StorageImpl destructor): cc
, can you please provide a small test-case to repro the issue ?
I'me using next C++ code, but can't reproduce this issue void toTest() { torch::Tensor inputTensor = torch::randn({1, 3, 256, 256}); (torch::kMPS); } Tested with the latest mps_graph branch build. Could you please provide a minimal reproducible test?
The crash is in torch::jit::Module so you'd likely need to be running a forward. I'll try to get a reproduce. It's not happening in Python which makes it a bit harder.
I've tried to reproduce with a Module, for that i've created test module using code for resnet18 from this sample And next created next C++ code std::vector&lt;torch::jit::IValueinputs; inputs.pushback(torch::ones({1, 3, 224, 224}).to(torch::kMPS)); at::Tensor output = module.forward(inputs).toTensor().to(torch::kCPU); std::cout &lt;&lt; (1,0, 5) &lt;&lt; 'n'; With this code I see no issues, it runs forward and prints expected output: -1.2350 -0.0649 0.2181 0.0655 -0.2242 [ CPUFloatType{1,5} ]
, removing the "High priority" label, as we are not able to reproduce the issue. Please provide us a failing case and we will take a look.
We weren't able to reproduce this issue, so I'll close it. Please reopen the issue if you see again. Thanks.

Discussion:
# Example of using Container class Net(nn.Container): def __init__(self): <del> super(Net, self).__init__( conv1 = nn.Conv2d(1, 20, 5), relu  = nn.ReLU() ) </del> <ins> super(Net, self).__init__() self.conv1 = nn.Conv2d(1, 20, 5) self.relu  = nn.ReLU() </ins> def forward(self, input): output = self.relu(self.conv1(x)) return output
Change:
When converting a tensor to dlpack, the strides of single-value tensors () should be normalized to . This is the fallout conclusion from . Here is a demo of what is wrong: Collecting environment information... PyTorch version: 1.10.0a0+git2aa19f3 Is debug build: False CUDA used to build PyTorch: Could not collect ROCM used to build PyTorch: N/A OS: Ubuntu 20.04.4 LTS (x8664) GCC version: (GCC) 9.4.0 Clang version: 12.0.1 ( ) CMake version: version 3.21.1 Libc version: glibc-2.31 Python version: 3.9.6 (default, Jul 11 2021, 03:39:48) [GCC 9.3.0] (64-bit runtime) Python platform: Linux-5.4.0-122-generic-x8664-with-glibc2.31 Is CUDA available: False CUDA runtime version: 11.2.152 GPU models and configuration: GPU 0: NVIDIA GeForce GTX 1660 SUPER Nvidia driver version: 470.141.03 cuDNN version: /usr/lib/x8664-linux- HIP runtime version: N/A MIOpen runtime version: N/A Is XNNPACK available: False Versions of relevant libraries: [pip3] mypy==0.812 [pip3] mypy-extensions==0.4.3 [pip3] numpy==1.21.2 [pip3] torch==1.10.0a0+git2aa19f3 [pip3] torchaudio==0.10.0a0+ [conda] magma-cuda112 2.5.2 1 pytorch [conda] mkl 2021.3.0 h726a3e6557 conda-forge [conda] mkl-include 2021.3.0 h726a3e6557 conda-forge [conda] numpy 1.21.2 py39hdbf815f0 conda-forge [conda] torch 1.12.0a0+git1f29b31 dev0 <develop[conda] torchaudio 0.10.0a0+ pypi0 pypi
does this capture the problem?
pinging the right person,

Discussion:
g = tanh(W_{ig} x + b_{ig} + W_{hc} h + b_{hg})  o = mathrm{sigmoid}(W_{io} x + b_{io} + W_{ho} h + b_{ho})  c' = f * c + i * g  <del> h' = o * tanh(c_t)  </del> <ins> h' = o * tanh(c')  </ins> end{array} Args:
Change:
When converting a tensor to dlpack, the strides of single-value tensors () should be normalized to . This is the fallout conclusion from . Here is a demo of what is wrong: Collecting environment information... PyTorch version: 1.10.0a0+git2aa19f3 Is debug build: False CUDA used to build PyTorch: Could not collect ROCM used to build PyTorch: N/A OS: Ubuntu 20.04.4 LTS (x8664) GCC version: (GCC) 9.4.0 Clang version: 12.0.1 ( ) CMake version: version 3.21.1 Libc version: glibc-2.31 Python version: 3.9.6 (default, Jul 11 2021, 03:39:48) [GCC 9.3.0] (64-bit runtime) Python platform: Linux-5.4.0-122-generic-x8664-with-glibc2.31 Is CUDA available: False CUDA runtime version: 11.2.152 GPU models and configuration: GPU 0: NVIDIA GeForce GTX 1660 SUPER Nvidia driver version: 470.141.03 cuDNN version: /usr/lib/x8664-linux- HIP runtime version: N/A MIOpen runtime version: N/A Is XNNPACK available: False Versions of relevant libraries: [pip3] mypy==0.812 [pip3] mypy-extensions==0.4.3 [pip3] numpy==1.21.2 [pip3] torch==1.10.0a0+git2aa19f3 [pip3] torchaudio==0.10.0a0+ [conda] magma-cuda112 2.5.2 1 pytorch [conda] mkl 2021.3.0 h726a3e6557 conda-forge [conda] mkl-include 2021.3.0 h726a3e6557 conda-forge [conda] numpy 1.21.2 py39hdbf815f0 conda-forge [conda] torch 1.12.0a0+git1f29b31 dev0 <develop[conda] torchaudio 0.10.0a0+ pypi0 pypi
does this capture the problem?
pinging the right person,

Discussion:
def load_url(url, model_dir=None, map_location=None): r"""Loads the Torch serialized object at the given URL. <del> If the object is already present in `model_dir`, it's deserialied and </del> <ins> If the object is already present in `model_dir`, it's deserialized and </ins> returned. The filename part of the URL should follow the naming convention ``filename-<sha256>.ext`` where ``<sha256>`` is the first eight or more digits of the SHA256 hash of the contents of the file. The hash is used to

The default value of `model_dir` is ``$TORCH_HOME/models`` where ``$TORCH_HOME`` defaults to ``~/.torch``. The default directory can be <del> overriden with the ``$TORCH_MODEL_ZOO`` environement variable. </del> <ins> overriden with the ``$TORCH_MODEL_ZOO`` environment variable. </ins> Args: url (string): URL of the object to download
Change:
Platforms: mac, macos This test was disabled because it is failing on master (). This fails again , so I disable this test pending the discussion in on how best to clean up these runners. cc
<!-- validation-comment-start --<bodyHello there! From the DISABLED prefix in this issue title, it looks like you are attempting to disable a test in PyTorch CI. The information I have parsed is below: Test name: Platforms for which to skip the test: mac, macos Within ~15 minutes, will be disabled in PyTorch CI for these platforms: mac, macos. Please verify that your test name looks correct, e.g., . To modify the platforms list, please include a line in the issue body, like below. The default action will disable the test for all platforms if no platforms list is specified. We currently support the following platforms: asan, linux, mac, macos, rocm, win, windows.</body<!-- validation-comment-end --
I don't think this is really sustainable (nor productive) as all tests will eventually fail with no space left on device error... Instead, we should be reclaiming space on those nodes...
Yeah, this is only a temporary measure while we continue the investigation in This test writes a 2GB file to disk I think. I'll bring up the issue again tomorrow to get help from the team. At the moment, I have no idea which one is responsible for filling up the disk.
mac M1 runners has been cleaned up, resolving this one
failing again
Got a fix here to increase the minimum space required on MacOS to be 6GB. The current threshold of 4GB is not big enough

Discussion:
going to be volatile. Volatility spreads accross the graph much easier than non-requiring gradient - you only need a **single** volatile leaf to have a volatile output, while you need **all** leaves to not require gradient to <del> have an output the doesn't require gradient. Using volatile flag you don't </del> <ins> have an output that doesn't require gradient. Using volatile flag you don't </ins> need to change any settings of your model parameters to use it for inference. It's enough to create a volatile input, and this will ensure that no intermediate states are saved.
Change:
While using torch on a Macbook pro with M1 ship, using python 3.8.10 and torch 1.12.1, I came across a weird bug that happened because I forgot to put a tensor on MPS. The reproducible code is the following: As you can see, if is on MPS and on CPU, the line wrongly replaces the index in place of the index . I would expect to have an error saying both tensors should be on the same device instead. I get an error: cc
The error seems to happen somewhere within Also I'm getting a warning "The operator 'aten::nonzero' is not currently supported on the MPS backend and will fall back to run on the CPU. This may have performance implications" when printing tensors on MPS.
Hi - thanks for reporting this issue. This is actually an allowed usecase (copying CPU tensors into MPS tensors / MPS -CPU / MPS -MPS): The issue is on MPS side when copying a CPU tensor into a strided MPS tensor. I'll take a look.

Discussion:
l1=l, l2=l ) <ins> self.param = Variable(torch.Tensor(3, 5)) </ins> l = nn.Linear(10, 20) n = Net() <del> s = nn.Sequential(l, l, l, l) </del> <ins> s = nn.Sequential(n, n, n, n) </ins> self.assertEqual(num_params(l), 2) <del> self.assertEqual(num_params(n), 2) self.assertEqual(num_params(s), 2) </del> <ins> self.assertEqual(num_params(n), 3) self.assertEqual(num_params(s), 3) def test_modules(self): class Net(nn.Container): def __init__(self): super(Net, self).__init__() self.l1 = l self.l2 = l self.param = Variable(torch.Tensor(3, 5)) l = nn.Linear(10, 20) n = Net() s = nn.Sequential(n, n, n, n) self.assertEqual(list(s.modules()), [s, n, l]) </ins> def test_Sequential_getitem(self): l1 = nn.Linear(10, 20)

def parameters(self, memo=None): if memo is None: memo = set() <del> super(Container, self).parameters(memo) </del> <ins> for p in super(Container, self).parameters(memo): yield p </ins> for module in self.children(): for p in module.parameters(memo): yield p

if memo is None: memo = set() if self not in memo: <del> super(Container, self).modules(memo) </del> <ins> for m in super(Container, self).modules(memo): yield m </ins> for module in self.children(): for m in module.modules(memo): yield m
Change:
! Maybe we should change it to `? No response cc
are these old installation commands also auto-tested with CI?
Looks no longer relevant.

Discussion:
arguments(), is_variadic(is_variadic), has_out(has_out) {}; Option(const Option&) = delete; Option(Option&& other): <del> arguments(std::move(other.arguments)), is_variadic(other.is_variadic) {}; </del> <ins> arguments(std::move(other.arguments)), is_variadic(other.is_variadic), has_out(other.has_out) {}; </ins> std::vector<Argument> arguments; bool is_variadic;
Change:
The use of in is deprecated a while ago, and the deprecation expired in Numpy 1.24+: Source: Minimal example: Error message with Numpy 1.24+: This error does not occur in Numpy 1.23.5. Numpy should have print a deprecation warning about this: but I think PyTorch has suppressed the warning.
(related: there are a few more numpy1.24 compatibility issues at )
so how can use add_histogram function in numpy 1.24.1?
Since this issue has been resolved, I believe you can use  as before (i.e., as in NumPy < 1.24).
I was using Python 3.9, torch 1.9.1 (with CUDA 11.1) and numpy 1.24.2 to run something today and still ran into this exact problem, don't really know about pytorch 2.0+ though. Thank you for the post though, otherwise might have cost me several more hours to figure this out.
I have this issue during yolo v7 training - cum_counts = (np.greater(counts, 0, dtype=np.int32)) TypeError: No loop matching the specified signature and casting was found for ufunc greater.
Hi, I'm still getting this error with numpy 1.24 and tensorboard 2.15.
same problem with numpy==1.24.3 torch==1.13.1+cu117 tensorboard==2.13.0
Same problem with numpy == 1.24.0 tensorboard == 2.14.0 torch == 1.13.1
Same problem with numpy == 1.26.4 tensorboard == 2.16.2 torch == 1.13.1+cu116
Using can solve this issue
same problem when I used with numpy==1.26.4 torch==1.13.0 tensorboard==2.16.2
go to the path of the in your or your main env like this -C:Userslegionanaconda3envsganLibsite-packagestorchutilstensorboard open and change following line to

Discussion:
limits = new_limits # Find the first and the last bin defining the support of the histogram: <del> cum_counts = np.cumsum(np.greater(counts, 0, dtype=np.int32)) </del> <ins> cum_counts = np.cumsum(np.greater(counts, 0)) </ins> start, end = np.searchsorted(cum_counts, [0, cum_counts[-1] - 1], side="right") start = int(start) end = int(end) + 1
Change:
Repro: stack: says he's already investigating a similar problem in internal models. cc
we think may be root cause
I think this might be correct? I am seeing CPU devices explicitly created in the model, and in dynamo. I do not believe this is a bug, but we need much better tooling around detecting devices.
In that case we need to add float16 support to the cpu backend (ugh)
The node being copied CPU=CUDA is: so the only CPU op involved is -- which we are actually generating ourselves. This patch might help, by doing the conversion on GPU: Though after applying it we get a new error:
After applying some partial fixes in pytorch/torchdynamo, I tried the minifier -- but it didn't seem to work. cc I was running I get a lot of printouts of: But then it finishes I get:
If I change where the cpu device is set to "cuda" in the model source - and remove an assert on our end, I can get the same exact error. That might make for an easier minification and repro story. Let me see if that minimizes on my end.
Please rebase to this PR,
pytorch/torchdynamo gets the same error without needing to do dtype conversion, potentially easier for debugging?
Minified version (requires pytorch/torchdynamo)
ref pytorch/torchdynamo

Discussion:
input=(torch.randn(2, 3, 5, 5, 5) * 1000)), OldModuleTest(nn.VolumetricMaxPooling, (2, 2, 2, 2, 2, 2), <del> input_size=(2, 3, 5, 5, 5), </del> <ins> input=(torch.randn(2, 3, 5, 5, 5) * 1000), </ins> desc='stride'), OldModuleTest(nn.VolumetricMaxPooling, (2, 2, 2, 2, 2, 2, 1, 1, 1), <del> input_size=(2, 3, 5, 5, 5), </del> <ins> input=(torch.randn(2, 3, 5, 5, 5) * 1000), </ins> desc='stride_padding'), OldModuleTest(nn.VolumetricReplicationPadding, (1, 2, 3, 4, 5, 6),
Change:
We should explore using TorchDynamo to capture/optimize optimizer code. I don't anticipate any major issues here, but we should make sure it plays nice with AOT Autograd. cc
linking issue related to performance of this:

Discussion:
- [Releases and Contributing](#releases-and-contributing) - [The Team](#the-team) <del> | Python |  **`Linux CPU`**   |  **`Linux GPU`** | |--------|--------------------|------------------| | 2.7.8  | [![Build Status](https://travis-ci.com/apaszke/pytorch.svg?token=shqHbUq29zKDxuqzGcjC&branch=master)](https://travis-ci.com/apaszke/pytorch) | | | 2.7    | [![Build Status](https://travis-ci.com/apaszke/pytorch.svg?token=shqHbUq29zKDxuqzGcjC&branch=master)](https://travis-ci.com/apaszke/pytorch) | [![Build Status](http://build.pytorch.org:8080/buildStatus/icon?job=pytorch-master-py2)](https://build.pytorch.org/job/pytorch-master-py2)  | | 3.5    | [![Build Status](https://travis-ci.com/apaszke/pytorch.svg?token=shqHbUq29zKDxuqzGcjC&branch=master)](https://travis-ci.com/apaszke/pytorch) | [![Build Status](http://build.pytorch.org:8080/buildStatus/icon?job=pytorch-master-py3)](https://build.pytorch.org/job/pytorch-master-py3)  | | Nightly| [![Build Status](https://travis-ci.com/apaszke/pytorch.svg?token=shqHbUq29zKDxuqzGcjC&branch=master)](https://travis-ci.com/apaszke/pytorch) | | </del> <ins> | System | Python | Status | | --- | --- | --- | | Linux CPU | 2.7.8, 2.7, 3.5, nightly | [![Build Status](https://travis-ci.org/pytorch/pytorch.svg?branch=master)](https://travis-ci.org/pytorch/pytorch) | | Linux GPU | 2.7 | [![Build Status](http://build.pytorch.org:8080/buildStatus/icon?job=pytorch-master-py2)](https://build.pytorch.org/job/pytorch-master-py2) | | Linux GPU | 3.5 | [![Build Status](http://build.pytorch.org:8080/buildStatus/icon?job=pytorch-master-py3)](https://build.pytorch.org/job/pytorch-master-py3) | </ins> ## More about PyTorch
Change:
This is a test. Please ignore it. Edited.
<!-- validation-comment-start --<bodyHello there! From the DISABLED prefix in this issue title, it looks like you are attempting to disable a job in PyTorch CI. The information I have parsed is below: Job name: Credential: Within ~15 minutes, and all of its dependants will be disabled in PyTorch CI. Please verify that the job name looks correct. With great power comes great responsibility. </body<!-- validation-comment-end --

Discussion:
// For Convolution strategies that don't implicitly handle grad_bias, we add a helper // function here to perform it using simple Tensor operators static at::Tensor compute_grad_bias(const at::Tensor& grad_output) { <del> // grad_output is in N, C, H, W, we re-shape and reduce over spatial dims and batches </del> <ins> // grad_output is in N, C, H, W, we re-shape and reduce over spatial dims and batches </ins> return grad_output.contiguous().view({grad_output.size(0), grad_output.size(1), -1}).sum(0).sum(1); }

gI = apply_fn<Transpose>(0, 1)(gIt); } } <ins> if (should_compute_output(0) && !ggO.defined()) ggO = at::zeros_like(gO); if (should_compute_output(1) && !gI.defined()) gI = at::zeros_like(input); if (should_compute_output(2) && !gW.defined()) gW = at::zeros_like(weight); </ins> return {ggO, gI, gW}; }
Change:
This is most obvious by observing binary sizes, for example on pypi: (6.0 MB ) (33.8 MB ) Also, from the build log it's clear that 3.8 for some reason build with flag: CI cc
Which is a good old

Discussion:
upstream="$1" pr="$2" git diff --name-only "$upstream" "$pr" <del> git diff --name-only "$upstream" "$pr" | grep -Eq '^(CMakeLists.txt|Makefile|.gitmodules|.jenkins/caffe2|binaries|caffe|caffe2|cmake|conda|docker|docs/caffe2|modules|scripts|third_party)' </del> <ins> # For safety, unconditionally trigger for any changes. #git diff --name-only "$upstream" "$pr" | grep -Eq '^(CMakeLists.txt|Makefile|.gitmodules|.jenkins/caffe2|binaries|caffe|caffe2|cmake|conda|docker|docs/caffe2|modules|scripts|third_party)' </ins>

upstream="$1" pr="$2" git diff --name-only "$upstream" "$pr" <del> git diff --name-only "$upstream" "$pr" | grep -Eq '^(aten/|caffe2/|.jenkins/pytorch|docs/(make.bat|Makefile|requirements.txt|source)|mypy|requirements.txt|setup.py|test/|third_party/|tools/|.gitmodules|torch/)' </del> <ins> # Now that PyTorch build depends on Caffe2, unconditionally trigger # for any changes. # TODO: Replace this with a NEGATIVE regex that allows us to blacklist # files (letting us skip builds when they are unnecessary) #git diff --name-only "$upstream" "$pr" | grep -Eq '^(aten/|caffe2/|.jenkins/pytorch|docs/(make.bat|Makefile|requirements.txt|source)|mypy|requirements.txt|setup.py|test/|third_party/|tools/|.gitmodules|torch/)' </ins>

unset(CUDA_ARCH_PTX CACHE) endif() <del> if(DEFINED ENV{TORCH_CUDA_ARCH_LIST}) </del> <ins> if($ENV{TORCH_CUDA_ARCH_LIST}) </ins> # Pass CUDA architecture directly set(__cuda_arch_bin $ENV{TORCH_CUDA_ARCH_LIST}) message(STATUS "Set CUDA arch from TORCH_CUDA_ARCH_LIST: ${__cuda_arch_bin}")
Change:
Link In the third example the doc shows torch.unflatten((5, 12, 3), -1, (2, 2, 3, 1, 1)).shape torch.Size([5, 2, 2, 3, 1, 1, 3]) which should be incorrect, the correct code should be torch.unflatten((5, 12, 3), -2, (2, 2, 3, 1, 1)).shape torch.Size([5, 2, 2, 3, 1, 1, 3]) No response cc
Thank you for reporting. Next time you spot a problem like that please do not hesitate to propose a PR with the fix.

Discussion:
torch.Size([3, 2, 2, 1]) >>> torch.unflatten(torch.randn(3, 4, 1), 1, (-1, 2)).shape torch.Size([3, 2, 2, 1]) <del> >>> torch.unflatten(torch.randn(5, 12, 3), -1, (2, 2, 3, 1, 1)).shape </del> <ins> >>> torch.unflatten(torch.randn(5, 12, 3), -2, (2, 2, 3, 1, 1)).shape </ins> torch.Size([5, 2, 2, 3, 1, 1, 3]) """.format( **common_args
Change:
There is a typo on the , in the Frequently Asked Questions. It says: Is that mean to be a joke (broken branch), or an actual typo? If it is meant to be a joke, please ignore this issue. I will be submitting a PR with the fix for the typo.
A typo for sure. I've force-merged your PR, thanks!

Discussion:
tasks or pull requests with your environment details is helpful and appreciated. -  **CI tests failed, what does it mean?** Maybe your PR is based <del> off a broken main bracnh? You can try to rebase your change on top </del> <ins> off a broken main branch? You can try to rebase your change on top </ins> of the latest main branch. You can also see the current status of main branch's CI at https://hud.pytorch.org/. -  **What are the most high risk changes?** Anything that touches build
Change:
Platforms: macos, mac This test was disabled because it is failing on main branch (). cc
<!-- validation-comment-start --<bodyHello there! From the DISABLED prefix in this issue title, it looks like you are attempting to disable a test in PyTorch CI. The information I have parsed is below: Test name: Platforms for which to skip the test: mac, macos Disabled by Within ~15 minutes, will be disabled in PyTorch CI for these platforms: mac, macos. Please verify that your test name looks correct, e.g., . To modify the platforms list, please include a line in the issue body, like below. The default action will disable the test for all platforms if no platforms list is specified. We currently support the following platforms: asan, dynamo, inductor, linux, mac, macos, rocm, slow, win, windows.</body<!-- validation-comment-end --

Discussion:
z3-solver==4.12.2.0 tensorboard==2.13.0 optree==0.9.1 <ins> # NB: test_hparams_* from test_tensorboard is failing with protobuf 5.26.0 in # which the stringify metadata is wrong when escaping double quote protobuf==3.20.2 </ins>
Change:
Repro is torchtrain w/ it happens more often if in my experience but it still happens either way. Logically its clear we have a race: rank0 is free to exit and shut down TCPStore before or after other ranks shut themselves down. we have to consider either a) rank 0 waits for all other ranks to exit before it exists b) we make other ranks tolerant of tcpstore going away (A) has potential downsides in efficiency even in the best case. But also practically, we could use tcpstore barrier, but it wont work reliably at large scales. we'd have to consider something like 'scalable coordinator' to go this route (B) we could probably implement w/ a try/catch in the heartbeat monitor for the connection error, similar to how we catch cuda driver exit. This feels a little hacky. Its important we somehow distinguish between the cases when we are actually shutting down and want to swallow the error, from cases where the is a tcpstore/network error during runtime and we actually want to raise the error. This points to (a) as a more correct direction. cc
do you have any update on "make torchrun share TCPStore instance with pytorch"? I think that is our "proper" fix for this problem, and in the meantime people can work around it by 1) sleeping on rank0 for a sufficiently long time (between 5-10s seemed plenty for 128rank jobs) simplest possible to not sleep long enough in edge cases 2) using a barrier at job shutdown such that rank0 (and tcsptore) are gauranteed alive.
was landed as a fix

Discussion:
raise ValueError("output_size should be a sequence containing " "2 or 4 elements, but it has a length of {}".format( len(output_size))) <del> out_sizew, out_sizeh = output_size sizew = ((input.size(3) - 1) * self.dw - 2 * self.padw + self.kw) </del> <ins> out_sizeh, out_sizew = output_size </ins> sizeh = ((input.size(2) - 1) * self.dh - 2 * self.padh + self.kh) <del> out_padw = out_sizew - sizew </del> <ins> sizew = ((input.size(3) - 1) * self.dw - 2 * self.padw + self.kw) </ins> out_padh = out_sizeh - sizeh <del> out_padw_ok = 0 <= out_padw < self.dw </del> <ins> out_padw = out_sizew - sizew </ins> out_padh_ok = 0 <= out_padh < self.dh <del> if not out_padw_ok or not out_padh_ok: </del> <ins> out_padw_ok = 0 <= out_padw < self.dw if not out_padh_ok or not out_padw_ok: </ins> raise ValueError(("requested an output size of {}x{}, but " "valid sizes range from {}x{} to {}x{} (for an input of " "{}x{})").format(out_sizeh, out_sizew, sizeh, sizew,