internlm/SWE-Fixer-Train-110K huggingface dataset:
Repository: pytorch/pytorch

Issue:
torch.distributions.uniform.Uniform.cdf() can return negative values or values above one
## Issue description

`torch.distributions.uniform.Uniform.cdf()` can return negative values or values above one because it does not do a range check like `log_prob()` in the same class does.

Relevant code in `cdf()`:

https://github.com/pytorch/pytorch/blob/825c3ca2d6deb505b39b6b988d28f28a7bd15f4d/torch/distributions/uniform.py#L70-L74

Range checking in `log_prob()`:

https://github.com/pytorch/pytorch/blob/825c3ca2d6deb505b39b6b988d28f28a7bd15f4d/torch/distributions/uniform.py#L63-L68

I can provide a pull request based on the range checking as done in the `log_prob()` method of the same class (although `log_prob()` throws an exception with scalar arguments because of these range checks while `cdf()` accepts scalar arguments).

## Code example

```
import torch
from torch.distributions.uniform import Uniform
uniform = Uniform(1,2)
print uniform.cdf(0), uniform.cdf(5)
```
will give

```
tensor(-1.) tensor(4.)
```

## System Info
```
Collecting environment information...
PyTorch version: 0.4.0
Is debug build: No
CUDA used to build PyTorch: Could not collect

OS: Mac OSX 10.13.4
GCC version: Could not collect
CMake version: version 3.11.0

Python version: 2.7
Is CUDA available: No
CUDA runtime version: 9.1.128
GPU models and configuration: Could not collect
Nvidia driver version: Could not collect
cuDNN version: Could not collect

Versions of relevant libraries:
[pip] numpy (1.14.2)
[pip] root-numpy (4.4.0)
[pip] torch (0.4.0)
[pip] torchvision (0.2.1)
[conda] Could not collect

```


Discussion:
We should just clamp the cdf to the unit interval. Can you please send a PR? cc @fritzo

Resolving patch:
diff --git a/torch/distributions/uniform.py b/torch/distributions/uniform.py
--- a/torch/distributions/uniform.py
+++ b/torch/distributions/uniform.py
@@ -71,7 +71,7 @@ def cdf(self, value):
         if self._validate_args:
             self._validate_sample(value)
         result = (value - self.low) / (self.high - self.low)
-        return result
+        return result.clamp(min=0, max=1)
 
     def icdf(self, value):
         if self._validate_args:


Test patch:
diff --git a/test/test_distributions.py b/test/test_distributions.py
--- a/test/test_distributions.py
+++ b/test/test_distributions.py
@@ -1126,6 +1126,10 @@ def test_uniform(self):
         self.assertEqual(uniform.log_prob(above_high).item(), -float('inf'), allow_inf=True)
         self.assertEqual(uniform.log_prob(below_low).item(), -float('inf'), allow_inf=True)
 
+        # check cdf computation when value outside range
+        self.assertEqual(uniform.cdf(below_low).item(), 0)
+        self.assertEqual(uniform.cdf(above_high).item(), 1)
+
         set_rng_seed(1)
         self._gradcheck_log_prob(Uniform, (low, high))
         self._gradcheck_log_prob(Uniform, (low, 1.0))
Repository: pytorch/pytorch

Issue:
[docs] Tensor.permute docs missing
https://pytorch.org/docs/master/tensors.html?highlight=permute#torch.Tensor.permute


Discussion:
I also found this issue when I tried to swap axes of a tensor. I googled an older doc [here](http://pytorch-zh.readthedocs.io/en/latest/_modules/torch/tensor.html) in the source code. Hope it helps.

Resolving patch:
diff --git a/torch/_tensor_docs.py b/torch/_tensor_docs.py
--- a/torch/_tensor_docs.py
+++ b/torch/_tensor_docs.py
@@ -1407,6 +1407,24 @@ def callable(a, b) -> number
 See :func:`torch.ormqr`
 """)
 
+
+add_docstr_all('permute',
+               r"""
+permute(*dims) -> Tensor
+
+Permute the dimensions of this tensor.
+
+Args:
+    *dims (int...): The desired ordering of dimensions
+
+Example:
+    >>> x = torch.randn(2, 3, 5)
+    >>> x.size()
+    torch.Size([2, 3, 5])
+    >>> x.permute(2, 0, 1).size()
+    torch.Size([5, 2, 3])
+""")
+
 add_docstr_all('potrf',
                r"""
 potrf(upper=True) -> Tensor


Test patch:
Repository: pytorch/pytorch

Issue:
Errors exporting model from PyTorch to Caffe2
## System Info

PyTorch 0.4.0 (installed with conda)
Caffe2 0.8.dev (installed with conda)
onnx-caffe2 1.0.0 (installed with pip)
macOS 10.13.4
Python 3.6.5
no CUDA

## Issue description

I'm trying to build a model with PyTorch, export it as a Caffe2 model, then use it in a C++ program.  I'm pretty sure the C++ code is correct.  At any rate, it works correctly if I use a model built directly with Caffe2.  But I run into various problems when using a PyTorch model.  Here is the code I use to generate it:

```python
import torch
import torch.nn as nn

class Compute(nn.Module):
    def forward(self, x):
        return torch.sum(x**2)

x = torch.rand(10, 3)
torch.onnx.export(Compute(), x, "test.onnx", verbose=True, input_names=['positions'], output_names=['energy'])
```

I convert it to a Caffe2 model with `convert-onnx-to-caffe2`, then try to execute it in my C++ program.  It fails with this error:

```
exception: [enforce fail at tensor.h:495] IsType<T>(). Tensor type mismatch, caller expects elements to be float while tensor contains long long Error from operator: 
input: "positions" input: "1" output: "2" name: "" type: "Pow" device_option { device_type: 0 cuda_gpu_id: 0 }
** while accessing input: 1
```

The problem appears to be the operation `x**2`.  PyTorch is recording the exponent as being a `long long`, but Caffe2 insists it must be a `float`.

As a temporary workaround, I tried eliminating the power operation by changing the line to `return torch.sum(x*x)`.  With that change I can run the model, but when I query the "energy" output, it's wrong.  It ought to be a scalar containing the sum of squares of all the input elements.  Instead, it comes out as a (10, 3) matrix containing the square of each element.  That is, the sum operation is never getting run.


Discussion:

Resolving patch:
diff --git a/torch/onnx/symbolic.py b/torch/onnx/symbolic.py
--- a/torch/onnx/symbolic.py
+++ b/torch/onnx/symbolic.py
@@ -631,7 +631,7 @@ def abs(g, self):
 
 
 def pow(g, self, exponent):
-    return g.op("Pow", self, exponent)
+    return g.op("Pow", self, _if_scalar_type_as(exponent, self), **_broadcast_if_scalar(exponent))
 
 
 def clamp(g, self, min, max):


Test patch:
Repository: pytorch/pytorch

Issue:
torch.save does not work with _LRSchedulers
## Issue description

``torch.save`` does not work with ``torch.optim.lr_scheduler._LRScheduler``

## Code example

Offending code:
```
from torch import nn
from torch.optim import Adam
from torch.optim.lr_scheduler import MultiStepLR

import torch

net = nn.LSTM(10, 10)
optimizer = Adam(params=filter(lambda p: p.requires_grad, net.parameters()))
scheduler = MultiStepLR(optimizer, milestones=[30, 80], gamma=0.1)

scheduler.step()  # This is Fine

# Check save and load into the directory work
torch.save(scheduler, 'scheduler.pt')
scheduler = torch.load('scheduler.pt')

scheduler.step()  # AttributeError: 'MultiStepLR' object has no attribute 'optimizer'
```

Stack trace:
```
Traceback (most recent call last):
  File "play.py", line 17, in <module>
    scheduler.step()  # AttributeError: 'MultiStepLR' object has no attribute 'optimizer'
  File "/usr/local/lib/python3.6/dist-packages/torch/optim/lr_scheduler.py", line 55, in step
    for param_group, lr in zip(self.optimizer.param_groups, self.get_lr()):
AttributeError: 'MultiStepLR' object has no attribute 'optimizer'
````

## System Info
- PyTorch or Caffe2: PyTorch
- How you installed PyTorch (conda, pip, source): pip
- PyTorch version: 0.4.0
- Python version: 3.6.4


Discussion:
This is due to _LRScheduler.state_dict explicitly excluding optimizer in state_dict(). https://github.com/pytorch/pytorch/blob/master/torch/optim/lr_scheduler.py#L37 Including it in state_dict() fixes the problem. Before I go ahead and make the PR, is there any other concern that we should not put optimizer in state_dict()? cc: @apaszke Thanks!
Yeah, `__getstate__` and `state_dict()` should really have different logic (with the first one including optimizer, while the second one would not).
Is including the optimizer a good idea though? I can imagine a code like this 

```python
optimizer = th.load(...)
scheduler = th.load(...)

scheduler.step() # this will not change lr of the loaded optimizer, but of the internal copy?
```

The same thing happens if you serialize a model and its optimizer in two separate checkpoints, so I'm not very concerned about that.

Resolving patch:
diff --git a/torch/optim/lr_scheduler.py b/torch/optim/lr_scheduler.py
--- a/torch/optim/lr_scheduler.py
+++ b/torch/optim/lr_scheduler.py
@@ -22,12 +22,6 @@ def __init__(self, optimizer, last_epoch=-1):
         self.step(last_epoch + 1)
         self.last_epoch = last_epoch
 
-    def __getstate__(self):
-        return self.state_dict()
-
-    def __setstate__(self, state):
-        self.load_state_dict(state)
-
     def state_dict(self):
         """Returns the state of the scheduler as a :class:`dict`.
 


Test patch:
Repository: pytorch/pytorch

Issue:
np.repeat vs torch.repeat
## Issue description

Numpy repeat and torch repeat have fundamentally different default behaviors. This was unexpected to me. This may be unexpected to other people. For me, this failed silently in my model, welp. 

numpy.repeat [1, 2, 3]  → [1, 1, 2, 2, 3, 3] 
torch.repeat [1, 2, 3] →  [1, 2, 3, 1, 2, 3]

I think it'd be nice to either change the default behavior or to add to the documentation a warning.


Discussion:
Easiest thing to do for now is to add a warning to the docs. One day we'll probably re-visit the all the differences between the Numpy API and pytorch API, but for now, just changing repeat might be disruptive to our users.

Feel free to submit a pull request @PetrochukM (otherwise, I can submit one).

Resolving patch:
diff --git a/torch/_tensor_docs.py b/torch/_tensor_docs.py
--- a/torch/_tensor_docs.py
+++ b/torch/_tensor_docs.py
@@ -1558,6 +1558,13 @@ def callable(a, b) -> number
 
 Unlike :meth:`~Tensor.expand`, this function copies the tensor's data.
 
+.. warning::
+
+    :func:`torch.repeat` behaves differently from
+    `numpy.repeat <https://docs.scipy.org/doc/numpy/reference/generated/numpy.repeat.html>`_,
+    but is more similar to
+    `numpy.tile <https://docs.scipy.org/doc/numpy/reference/generated/numpy.tile.html>`_.
+
 Args:
     sizes (torch.Size or int...): The number of times to repeat this tensor along each
         dimension


Test patch:
Repository: pytorch/pytorch

Issue:
[Docs] [Low Priority] Pytorch docs in Google search points to master/unstable
When I googled `pytorch nn functional`, this came up as the first link: `pytorch.org/docs/master/_modules/torch/nn/functional.html`

This is, as you know, docs for the master/unstable version. On clicking the link which says it'll take me to the docs for the stable release, I get sent to the home page of the docs, and now I have to search for the page again.

This can be solved by adding a canonical link to their non-stable documentation, i.e. something like this: `<link rel="canonical" href="https://pytorch.org/docs/stable/nn.html#torch-nn-functional">`.


Discussion:
I've noticed this before but I didn't know there was a way to solve it. Thanks @sherjilozair for the idea; I'll try it out and see how it goes -- this would definitely be a great improvement. (You should also feel free to submit a PR if you'd like!)
This is what Python documentation uses. See, eg.: view-source:https://docs.python.org/3.8/library/functions.html 

It would take time for Google's SEO to update though.

Resolving patch:
diff --git a/docs/source/conf.py b/docs/source/conf.py
--- a/docs/source/conf.py
+++ b/docs/source/conf.py
@@ -115,6 +115,7 @@
 # documentation.
 #
 html_theme_options = {
+    'canonical_url': 'https://pytorch.org/docs/stable/',
     'collapse_navigation': False,
     'display_version': True,
     'logo_only': True,


Test patch:
Repository: pytorch/pytorch

Issue:
[documentation request] 'clone' needs better documentation
[The current documentation for `Tensor.clone` is](https://pytorch.org/docs/stable/tensors.html?highlight=clone#torch.Tensor.clone):

> Returns a copy of the `self` tensor. The copy has the same size and data type as `self`.

This documentation fails to elucidate the fact that any gradient propagating through the cloned tensor will propagate to the original tensor. This is critical to the functionality of clone (and is why the method isn't called "copy"), and is just begging for newcomers to make hard-to-find mistakes. 


Discussion:
Thanks for the report, @rsokl. Please feel free to send a pr!

Resolving patch:
diff --git a/torch/_tensor_docs.py b/torch/_tensor_docs.py
--- a/torch/_tensor_docs.py
+++ b/torch/_tensor_docs.py
@@ -516,6 +516,11 @@ def add_docstr_all(method, docstr):
 
 Returns a copy of the :attr:`self` tensor. The copy has the same size and data
 type as :attr:`self`.
+
+.. note::
+
+    Unlike `copy_()`, this function is recorded in the computation graph. Gradients
+    propagating to the cloned tensor will propagate to the original tensor.
 """)
 
 add_docstr_all('contiguous',


Test patch:
Repository: pytorch/pytorch

Issue:
Loaded network with load_state_dict has different shape but works anyway
After it was verified on [discuss.pytorch](https://discuss.pytorch.org/t/loaded-network-has-different-shape-but-works-anyway/19398) that this is indeed unwanted behaviour, I am forwarding this to you:

## Issue description

I trained a model with among others had the following layer:
`final_layer.append(nn.Conv2d(64, 1, kernel_size=1))`
and then saved it to a file with state_dict and torch.save.

Then, when I wanted to load that model using load_state_dict, by accident the same layer was setup as follows:
`final_layer.append(nn.Conv2d(64, 32, kernel_size=1))`

Nevertheless, the model was loaded without error. It seemed that the weights were just duplicated 32 times, but I have not verified. So the question is how this is consistent with API documentation. I have not found a statement that says load_state_dict would somehow fix shape inconsistencies automatically. It seems you have a documentation vs reality mismatch here. (Now you need to decide which one to fix)

## Code example

```
path = './test_model.pth'

model = nn.Conv2d(64, 1, 3, 1, 1)
torch.save(model.state_dict(), path)

model = nn.Conv2d(64, 32, 3, 1, 1)
model.load_state_dict(torch.load(path))

for w in model.weight[:, :, 0, 0]:
    print(w)
```

Provided by discuss .pytorch user ptrblck

## System Info
pytorch 0.4 release




Discussion:
we should check for exact shape match at https://github.com/pytorch/pytorch/blob/master/torch/nn/modules/module.py#L636

Resolving patch:
diff --git a/torch/nn/modules/module.py b/torch/nn/modules/module.py
--- a/torch/nn/modules/module.py
+++ b/torch/nn/modules/module.py
@@ -629,6 +629,13 @@ def _load_from_state_dict(self, state_dict, prefix, strict, missing_keys, unexpe
             key = prefix + name
             if key in state_dict:
                 input_param = state_dict[key]
+
+                if input_param.shape != param.shape:
+                    # local shape should match the one in checkpoint
+                    error_msgs.append('Size mismatch: copying a param of {} from checkpoint, '
+                                      'where the shape is {} in current model.'
+                                      .format(param.shape, input_param.shape))
+
                 if isinstance(input_param, Parameter):
                     # backwards compatibility for serialized parameters
                     input_param = input_param.data


Test patch:
Repository: pytorch/pytorch

Issue:
warn/error when using gradcheck with < float64 precision
Should prevent error usages like https://github.com/pytorch/pytorch/issues/8649


Discussion:

Resolving patch:
diff --git a/torch/autograd/gradcheck.py b/torch/autograd/gradcheck.py
--- a/torch/autograd/gradcheck.py
+++ b/torch/autograd/gradcheck.py
@@ -3,6 +3,7 @@
 import torch.testing
 import sys
 from itertools import product
+import warnings
 
 
 def zero_gradients(x):
@@ -163,6 +164,12 @@ def gradcheck(func, inputs, eps=1e-6, atol=1e-5, rtol=1e-3, raise_exception=True
     # Make sure that gradients are saved for all inputs
     for inp in tupled_inputs:
         if isinstance(inp, torch.Tensor):
+            if inp.requires_grad and inp.dtype != torch.float64:
+                warnings.warn(
+                    'At least one of the inputs that requires gradient \
+                     is not of double precision floating point. '
+                    'This check will likely fail if all the inputs are not of \
+                     double precision floating point. ')
             inp.retain_grad()
 
     output = _differentiable_outputs(func(*inputs))


Test patch:
Repository: pytorch/pytorch

Issue:
nn.init.eye_ sets requires_grad to False on tensors
repro:
```
import torch.nn as nn
L = nn.Linear(5,5)
nn.init.eye_(L.weight)
print(L.weight.requires_grad)  # False
```

Initially reported from https://discuss.pytorch.org/t/since-0-4-using-nn-init-eye-disables-gradient/19999/2
nn.init.eye_ sets requires_grad to False on tensors
repro:
```
import torch.nn as nn
L = nn.Linear(5,5)
nn.init.eye_(L.weight)
print(L.weight.requires_grad)  # False
```

Initially reported from https://discuss.pytorch.org/t/since-0-4-using-nn-init-eye-disables-gradient/19999/2


Discussion:

Resolving patch:
diff --git a/torch/nn/init.py b/torch/nn/init.py
--- a/torch/nn/init.py
+++ b/torch/nn/init.py
@@ -140,7 +140,7 @@ def eye_(tensor):
         raise ValueError("Only tensors with 2 dimensions are supported")
 
     with torch.no_grad():
-        torch.eye(*tensor.shape, out=tensor)
+        torch.eye(*tensor.shape, out=tensor, requires_grad=tensor.requires_grad)
     return tensor
 
 


Test patch:
Repository: pytorch/pytorch

Issue:
nn.NLLLoss example throws error
## `nn.NLLLoss` example does not work in current stable and master doc.

Reported [in this thread](https://discuss.pytorch.org/t/help-understanding-nn-nllloss-example/20153).

The second example of `nn.NLLLoss`  from [the docs](https://pytorch.org/docs/master/nn.html?#torch.nn.NLLLoss) throws an error on creating the `target` `tensor`:
```python
# 2D loss example (used, for example, with image inputs)
N, C = 5, 4
loss = nn.NLLLoss()
# input is of size N x C x height x width
data = torch.randn(N, 16, 10, 10)
m = nn.Conv2d(16, C, (3, 3))
# each element in target has to have 0 <= value < C
target = torch.tensor(N, 8, 8).random_(0, C)
> TypeError: tensor() takes 1 positional argument but 3 were given
output = loss(m(data), target)
output.backward()
```

Tested under `0.4.0` and `0.5.0a0+e62c3a4`.

The fix could be:
```python
target = torch.empty(N, 8, 8, dtype=torch.long).random_(0, C)
```
I'm creating a pull request to fix this issue.
nn.NLLLoss example throws error
## `nn.NLLLoss` example does not work in current stable and master doc.

Reported [in this thread](https://discuss.pytorch.org/t/help-understanding-nn-nllloss-example/20153).

The second example of `nn.NLLLoss`  from [the docs](https://pytorch.org/docs/master/nn.html?#torch.nn.NLLLoss) throws an error on creating the `target` `tensor`:
```python
# 2D loss example (used, for example, with image inputs)
N, C = 5, 4
loss = nn.NLLLoss()
# input is of size N x C x height x width
data = torch.randn(N, 16, 10, 10)
m = nn.Conv2d(16, C, (3, 3))
# each element in target has to have 0 <= value < C
target = torch.tensor(N, 8, 8).random_(0, C)
> TypeError: tensor() takes 1 positional argument but 3 were given
output = loss(m(data), target)
output.backward()
```

Tested under `0.4.0` and `0.5.0a0+e62c3a4`.

The fix could be:
```python
target = torch.empty(N, 8, 8, dtype=torch.long).random_(0, C)
```
I'm creating a pull request to fix this issue.


Discussion:

Resolving patch:
diff --git a/torch/nn/modules/loss.py b/torch/nn/modules/loss.py
--- a/torch/nn/modules/loss.py
+++ b/torch/nn/modules/loss.py
@@ -172,7 +172,7 @@ class NLLLoss(_WeightedLoss):
         >>> data = torch.randn(N, 16, 10, 10)
         >>> m = nn.Conv2d(16, C, (3, 3))
         >>> # each element in target has to have 0 <= value < C
-        >>> target = torch.tensor(N, 8, 8).random_(0, C)
+        >>> target = torch.empty(N, 8, 8, dtype=torch.long).random_(0, C)
         >>> output = loss(m(data), target)
         >>> output.backward()
     """


Test patch:
Repository: pytorch/pytorch

Issue:
torch.nn.functional.grid_sample should throw error for invalid mode
The only valid mode is 'bilinear', but one can pass anything to it and it will not complain:
```
torch.nn.functional.grid_sample(array_5d, indices, mode='anything')
```


Discussion:
Apparently, the `mode` is not passed to the backend function for `grid_sample`. I think it should be removed.
Yes. I think the idea is that we'd like to support other modes at some point.

Resolving patch:
diff --git a/torch/nn/functional.py b/torch/nn/functional.py
--- a/torch/nn/functional.py
+++ b/torch/nn/functional.py
@@ -1902,6 +1902,8 @@ def grid_sample(input, grid, mode='bilinear', padding_mode='zeros'):
         output (Tensor): output Tensor
 
     """
+    if mode != 'bilinear':
+        raise NotImplementedError("nn.functional.grid_sample got unsupported mode: '{}'".format(mode))
     return vision.grid_sampler(input, grid, padding_mode)
 
 


Test patch:
diff --git a/test/test_nn.py b/test/test_nn.py
--- a/test/test_nn.py
+++ b/test/test_nn.py
@@ -4574,6 +4574,10 @@ def test_cosine_similarity(self):
         input2 = torch.randn(input_size, requires_grad=True)
         self.assertEqual(F.cosine_similarity(input1, input2, dim=1).size(), expected_size)
 
+    def test_grid_sample_unsupported_mode(self):
+        with self.assertRaisesRegex(NotImplementedError, "nn.functional.grid_sample got unsupported mode: 'garbage'"):
+            F.grid_sample(torch.tensor([]), torch.tensor([]), mode='garbage')
+
     def test_grid_sample(self):
         def test_cpu_against_cuda(N, C, H, W, padding_mode):
             def test_shape(N, C, IH, IW, H, W, padding_mode):