jiebi/CodeConvo huggingface dataset:
Change:
That's pretty big! In contrast, an OS X build log is only 1.3M. Is there a reason they have to be this big? CC
My guess is that it's because of warnings. I remember having to get through thousands of them when looking for the error that failed the build.
Yes, the major part of them are warnings. And some of them is not fixable. We can hide them using some flags on the compilers.
And this build configuration actually contains both the CPU and GPU build, which may also be a possible reason.
The reduced log size after PR is about 1.2M.

Discussion:
INCLUDE(CheckCXXSourceCompiles) <ins> # disable some verbose warnings IF (MSVC) set(CMAKE_CXX_FLAGS "/wd4267 /wd4251 /wd4522 /wd4522 /wd4838 /wd4305 /wd4244 /wd4190 /wd4101 /wd4996 /wd4275 ${CMAKE_CXX_FLAGS}") ENDIF(MSVC) </ins> # windef.h will define max/min macros if NOMINMAX is not defined IF(MSVC) add_definitions(/DNOMINMAX)

IF(MSVC) # we want to respect the standard, and we are bored of those **** . ADD_DEFINITIONS(-D_CRT_SECURE_NO_DEPRECATE=1) <del> LIST(APPEND CUDA_NVCC_FLAGS "-Xcompiler /wd4819 -Xcompiler /wd4503") </del> <ins> LIST(APPEND CUDA_NVCC_FLAGS "-Xcompiler /wd4819 -Xcompiler /wd4503 -Xcompiler /wd4190 -Xcompiler /wd4244 -Xcompiler /wd4251 -Xcompiler /wd4275 -Xcompiler /wd4522") </ins> ADD_DEFINITIONS(-DTH_EXPORTS) IF (NOT NO_CUDA) ADD_DEFINITIONS(-DTHC_EXPORTS)

extra_link_args = [] if IS_WINDOWS: <del> extra_compile_args = ['/Z7', '/EHa', '/DNOMINMAX' </del> <ins> extra_compile_args = ['/Z7', '/EHa', '/DNOMINMAX', '/wd4267', '/wd4251', '/wd4522', '/wd4522', '/wd4838', '/wd4305', '/wd4244', '/wd4190', '/wd4101', '/wd4996', '/wd4275' </ins> # /Z7 turns on symbolic debugging information in .obj files # /EHa is about native C++ catch support for asynchronous # structured exception handling (SEH) # /DNOMINMAX removes builtin min/max functions <ins> # /wdXXXX disables warning no. XXXX </ins> ] if sys.version_info[0] == 2: # /bigobj increases number of sections in .obj file, which is needed to link
Change:
When I try to train my model which contains MaxPool3d , It always end up with 'out of memory' error. my environment info is here: 16.04 PyTorch version: 0.4.0a0+ installed PyTorch from source python version is 3.6.2 CUDA/cuDNN version: 9.1/7.1.2 GCC version (if compiling from source):GCC 5.4 Build command you used (if compiling from source): as default I can reproduce this bug by the following script:
Thanks for the report, I can reproduce this and am looking into it.

Discussion:
// TODO: gradOutput shape check // Resize and initialize result tensor. THCTensor_(resizeAs)(state, gradInput, input); <del> THCTensor_(newContiguous)(state, gradInput); </del> THCTensor_(zero)(state, gradInput); int batchSize;
Change:
I am currently using PyTorch 0.3.0 and I am noticing some (possibly strange) differences between the behavior of when operating on CPU tensors versus GPU ones, in particular relating to whether the number of rows of A is allowed to be larger than the number of columns or not. Here is some minimal code that reproduces my problem: The first solve on the CPU works fine; however, the second solve gives me the error: Is this a limitation of the CUDA implementation of that PyTorch uses, or otherwise intended? If so, any guidance about a possible work-around would be greatly appreciated. Our only thought on a work-around was to manually QR decompose A with and then use , but doesn't support CUDA tensors.
MAGMA gels doesn't implement the m < n case.

Discussion:
#ifdef USE_MAGMA THArgCheck(a_->nDimension == 2, 1, "A should be 2 dimensional"); THArgCheck(b_->nDimension == 2, 1, "b should be 2 dimensional"); <del> THArgCheck(a_->size[0] == b_->size[0], 2, "size incompatible A,b"); THArgCheck(a_->size[0] >= a_->size[1], 2, "A should have m >= n"); </del> <ins> THArgCheck(a_->size[0] == b_->size[0], 2, "Expected A and b to have same size " "at dim 0, but they have incompatible sizes"); THArgCheck(a_->size[0] >= a_->size[1], 2, "Expected A with shape (m x n) to have " "m >= n. The case for m < n is not implemented yet."); </ins> THCTensor *a = THCTensor_(newColumnMajor)(state, ra_, a_); THCTensor *b = THCTensor_(newColumnMajor)(state, rb_, b_);
Change:
has a memory leak on the GPU when using PyTorch version 0.3.1. The memory leak goes away if I downgrade to PyTorch 0.3.0. I was able to reproduce the memory leak on 3 separate machines using P100s, 1080TIs and Titan Xs.How you installed PyTorch (conda, pip, source): conda OS: Ubuntu 16.04 PyTorch version: 0.3.1.post3 Python version: 3.6.3 CUDA version: 8.0.61 GPU models and configuration: 4x P100s, 2x 1080 TIs, 4x Titan X (3 separate machines)
thanks for the report. I can reproduce the bug on master. We'll get it fixed.

Discussion:
THCTensor *newValues = THCTensor_(newNarrow)(state, sorted, dimension, k, 1); THCudaLongTensor *newIndices = THCudaLongTensor_newNarrow(state, sorted_indices, dimension, k, 1); <ins> THCTensor_(free)(state, sorted); THCudaLongTensor_free(state, sorted_indices); </ins> if (!keepdim) { THCTensor_(squeeze1d)(state, newValues, newValues, dimension); THCudaLongTensor_squeeze1d(state, newIndices, newIndices, dimension);
Change:
+69 I read: To me, it should be: The CPU code is not affected.
The two lines of code are identical?
No, one is mu times moment time lr times grad instead of mu times moment plus lr times grad.
I see. Send a PR? :)
Will do :)

Discussion:
const float lr = *lr_ptr; if (!nesterov) { CUDA_1D_KERNEL_LOOP(i, N) { <del> moment_out[i] = mu * moment[i] * lr * grad[i]; </del> <ins> moment_out[i] = mu * moment[i] + lr * grad[i]; </ins> param_out[i] = param[i] - moment_out[i]; } } else {
Change:
The example given in the docs for newzeros() is actually an example for newones(). Should be a trivial fix. (Sorry, not quite sure what the etiquette/process is for fixing small errors like these). Thanks. The example should read:
Thanks for the catch, If you'd like to take a stab at fixing it, you can fork the pytorch repo and contribute a pull request. Otherwise, I can make the replacement.
fixed via

Discussion:
Example:: >>> tensor = torch.tensor((), dtype=torch.float64) <del> >>> tensor.new_ones((2, 3)) tensor([[ 1.,  1.,  1.], [ 1.,  1.,  1.]], dtype=torch.float64) </del> <ins> >>> tensor.new_zeros((2, 3)) tensor([[ 0.,  0.,  0.], [ 0.,  0.,  0.]], dtype=torch.float64) </ins> """.format(**new_common_args))
Change:
We're not testing against CUDA 9.2 and we should. C.f. We should test against GCC 7 (because this is how Anaconda is building the packages), AND we should use test with this in OS X, because CUDA 9.2 now supports the default xcode shipped on OS X.
Building PyTorch with CUDA 9.2 for 7.0 compute compatibility devices produces quite worrisome warnings: warning : Instruction 'vote' without '.sync' may produce unpredictable results on sm70 and later architectures warning : Instruction 'vote' without '.sync' is deprecated since PTX ISA version 6.0 and will be discontinued in a future PTX ISA version warning : Instruction 'shfl' without '.sync' is deprecated since PTX ISA version 6.0 and will be discontinued in a future PTX ISA version warning : Instruction 'shfl' without '.sync' may produce unpredictable results on sm70 and later architectures
CUDA 9.2 CI on macOS is done in

Discussion:
fi # sccache will fail for CUDA builds if all cores are used for compiling <del> # gcc 7.2 with sccache seems to have intermittent OOM issue if all cores are used if ([[ "$BUILD_ENVIRONMENT" == *cuda* ]] || [[ "$BUILD_ENVIRONMENT" == *gcc7.2* ]]) && which sccache > /dev/null; then </del> <ins> # gcc 7 with sccache seems to have intermittent OOM issue if all cores are used if ([[ "$BUILD_ENVIRONMENT" == *cuda* ]] || [[ "$BUILD_ENVIRONMENT" == *gcc7* ]]) && which sccache > /dev/null; then </ins> export MAX_JOBS=`expr $(nproc) - 1` fi

fi if [[ "$BUILD_ENVIRONMENT" == *pytorch-linux-xenial-cuda9-cudnn7-py3 ]] ||  <del> [[ "$BUILD_ENVIRONMENT" == *pytorch-linux-trusty-py3.6-gcc7.2 ]]; then </del> <ins> [[ "$BUILD_ENVIRONMENT" == *pytorch-linux-trusty-py3.6-gcc7* ]]; then </ins> BUILD_TEST_LIBTORCH=1 else BUILD_TEST_LIBTORCH=0

pytorch-linux-xenial-cuda9-cudnn7-py2-test pytorch-linux-xenial-cuda9-cudnn7-py3-build pytorch-linux-xenial-cuda9-cudnn7-py3-test <ins> pytorch-linux-xenial-cuda9.2-cudnn7-py3-gcc7-build pytorch-linux-xenial-cuda9.2-cudnn7-py3-gcc7-test </ins> pytorch-linux-xenial-py3-clang5-asan-build pytorch-linux-xenial-py3-clang5-asan-test pytorch-linux-trusty-py2.7.9-build

pytorch-linux-trusty-py3.6-gcc5.4-test pytorch-linux-trusty-py3.6-gcc7.2-build pytorch-linux-trusty-py3.6-gcc7.2-test <ins> pytorch-linux-trusty-py3.6-gcc7-build pytorch-linux-trusty-py3.6-gcc7-test </ins> pytorch-linux-trusty-pynightly-build pytorch-linux-trusty-pynightly-test pytorch-win-ws2016-cuda9-cudnn7-py3-build
Change:
[pytorch] The docs say that for tensor comparison operators (gt,lt etc) it should be possible to pass out argument typed as input (), yet when I try to do it, I hit an error Should the docs be fixed, or is it a bug?
If it's really useful we can add it back; but we'll fix the docs for now

Discussion:
Args: input (Tensor): the tensor to compare other (Tensor or float): the tensor or value to compare <del> out (Tensor, optional): the output tensor. Must be a `ByteTensor` or the same type as `input`. </del> <ins> out (Tensor, optional): the output tensor. Must be a `ByteTensor` </ins> Returns: Tensor: A ``torch.ByteTensor`` containing a 1 at each location where comparison is true

Args: input (Tensor): the tensor to compare other (Tensor or float): the tensor or value to compare <del> out (Tensor, optional): the output tensor that must be a `ByteTensor` or the same type as :attr:`input` </del> <ins> out (Tensor, optional): the output tensor that must be a `ByteTensor` </ins> Returns: Tensor: A ``torch.ByteTensor`` containing a 1 at each location where comparison is true

Args: input (Tensor): the tensor to compare other (Tensor or float): the tensor or value to compare <del> out (Tensor, optional): the output tensor that must be a `ByteTensor` or the same type as :attr:`input` </del> <ins> out (Tensor, optional): the output tensor that must be a `ByteTensor` </ins> Returns: Tensor: A `torch.ByteTensor` containing a 1 at each location where comparison is true

Args: input (Tensor): the tensor to compare other (Tensor or float): the tensor or value to compare <del> out (Tensor, optional): the output tensor that must be a `ByteTensor` or the same type as `input` </del> <ins> out (Tensor, optional): the output tensor that must be a `ByteTensor` </ins> Returns: Tensor: A ``torch.ByteTensor`` containing a 1 at each location where comparison is true.
Change:
CC If no one has time to investigate we should disable this test.
Sounds like a float-point precision issue? Maybe replacing EXPECTFLOATEQ with EXPECT_NEAR can help.

Discussion:
y_cpu_nhwc.data<float>(), y_cpu_nhwc.size()); int max_diff_idx = -1; (y_cpu_vec - y_gpu_vec).cwiseAbs().maxCoeff(&max_diff_idx); <del> EXPECT_FLOAT_EQ(y_cpu_vec[max_diff_idx], y_gpu_vec[max_diff_idx]); </del> <ins> EXPECT_NEAR(y_cpu_vec[max_diff_idx], y_gpu_vec[max_diff_idx], 1e-1); </ins> max_diff_idx = -1; (y_cpu_vec - y_cpu_nhwc_vec).cwiseAbs().maxCoeff(&max_diff_idx);
Change:
Considering the merge of and , and the "removal" of from the API, there are still some messages that reference . This might prove to be confusing for new users starting off from , as they probably might not have heard of . I did a code search to find out multiple instances of this in . PyTorch or Caffe2: PyTorch How you installed PyTorch (conda, pip, source): source (@ ) Build command you used (if compiling from source): OS: Ubuntu 16.04.2 PyTorch version: Python version: 3.5 CUDA/cuDNN version: 8.0.44 GPU models and configuration: GeForce 940M GCC version (if compiling from source): 5.4.0 CMake version: 3.5.1

Discussion:
for (int i = 0; i < required_args; ++i) { if (!inputs[i].defined()) { std::stringstream ss; <del> ss << name << ": expected Variable at argument " << i << " (got None)"; </del> <ins> ss << name << ": expected Tensor at argument " << i << " (got None)"; </ins> throw std::runtime_error(ss.str()); } }

// a test for Py_None here; instead, you need to mark the argument // as *allowing none*; you can do this by writing 'Tensor?' instead // of 'Tensor' in the ATen metadata. <del> throw TypeError("expected Variable as argument %d, but got %s", i, </del> <ins> throw TypeError("expected Tensor as argument %d, but got %s", i, </ins> Py_TYPE(args[i])->tp_name); } return reinterpret_cast<THPVariable*>(args[i])->cdata;

for (int idx = 0; idx < size; idx++) { PyObject* obj = tuple ? PyTuple_GET_ITEM(arg, idx) : PyList_GET_ITEM(arg, idx); if (!THPVariable_Check(obj)) { <del> throw TypeError("expected Variable as element %d in argument %d, but got %s", </del> <ins> throw TypeError("expected Tensor as element %d in argument %d, but got %s", </ins> idx, i, Py_TYPE(args[i])->tp_name); } res[idx] = reinterpret_cast<THPVariable*>(obj)->cdata;
Change:
Leaving this issue here for higher visibility. Originally reported by here: Also mentioned by Piggybacking off of this issue, has strange behavior (reported here: )
I have fixed this locally. Could I send a PR?
Yes, go ahead!

Discussion:
.. automethod:: log2 .. automethod:: log2_ .. automethod:: log_normal_ <ins> .. automethod:: logsumexp </ins> .. automethod:: long .. automethod:: lt .. automethod:: lt_

.. autofunction:: cumprod .. autofunction:: cumsum .. autofunction:: dist <ins> .. autofunction:: logsumexp </ins> .. autofunction:: mean .. autofunction:: median .. autofunction:: mode

For summation index :math:`j` given by `dim` and other indices :math:`i`, the result is <del> :math:`text{logsumexp}(x)_{i} = log sum_j exp(x_ij).` </del> <ins> .. math:: text{logsumexp}(x)_{i} = log sum_j exp(x_{ij}) </ins> If :attr:`keepdim` is ``True``, the output tensor is of the same size as :attr:`input` except in the dimension :attr:`dim` where it is of size 1.

import torch from torch.distributions import constraints from torch.distributions.distribution import Distribution <del> from torch.distributions.utils import probs_to_logits, logits_to_probs, log_sum_exp, lazy_property, broadcast_all </del> <ins> from torch.distributions.utils import probs_to_logits, logits_to_probs, _log_sum_exp, lazy_property, broadcast_all </ins> class Categorical(Distribution):

if probs is not None: self.probs = probs / probs.sum(-1, keepdim=True) else: <del> self.logits = logits - log_sum_exp(logits) </del> <ins> self.logits = logits - _log_sum_exp(logits) </ins> self._param = self.probs if probs is not None else self.logits self._num_events = self._param.size()[-1] batch_shape = self._param.size()[:-1] if self._param.ndimension() > 1 else torch.Size()

import torch from torch.distributions import constraints from torch.distributions.categorical import Categorical <del> from torch.distributions.utils import clamp_probs, broadcast_all, log_sum_exp </del> <ins> from torch.distributions.utils import clamp_probs, broadcast_all, _log_sum_exp </ins> from torch.distributions.distribution import Distribution from torch.distributions.transformed_distribution import TransformedDistribution from torch.distributions.transforms import ExpTransform

uniforms = clamp_probs(self.logits.new(self._extended_shape(sample_shape)).uniform_()) gumbels = -((-(uniforms.log())).log()) scores = (self.logits + gumbels) / self.temperature <del> return scores - log_sum_exp(scores) </del> <ins> return scores - _log_sum_exp(scores) </ins> def log_prob(self, value): K = self._categorical._num_events

log_scale = (self.temperature.new(self.temperature.shape).fill_(K).lgamma() - self.temperature.log().mul(-(K - 1))) score = logits - value.mul(self.temperature) <del> score = (score - log_sum_exp(score)).sum(-1) </del> <ins> score = (score - _log_sum_exp(score)).sum(-1) </ins> return score + log_scale

return value.reshape(required_shape).sum(-1) <del> def log_sum_exp(tensor, keepdim=True): </del> <ins> def _log_sum_exp(tensor, keepdim=True): </ins> r""" Numerically stable implementation for the `LogSumExp` operation. The summing is done along the last dimension.
Change:
Mac OS X builds failing this way. This appears to be correlated with worker-macos-high-sierra-2 and worker-macos-high-sierra-16.

Discussion:
export CMAKE_PREFIX_PATH=${PYTORCH_ENV_DIR}/miniconda3/ # Test PyTorch <ins> if [[ "${JOB_BASE_NAME}" == *cuda9.2* ]]; then # Eigen gives "explicit specialization of class must precede its first use" error # when compiling with Xcode 9.1 toolchain, so we have to use Xcode 8.2 toolchain instead. export DEVELOPER_DIR=/Library/Developer/CommandLineTools else export DEVELOPER_DIR=/Applications/Xcode9.app/Contents/Developer fi </ins> export MACOSX_DEPLOYMENT_TARGET=10.9 export CXX=clang++ export CC=clang
Change:
, thank you! The documentation for avgpool2d/3d says Indeed, the default was just that up to PyTorch 0.2. In 0.3-0.4 the default is False for 2d/3d and True 1d and the doc says it was True for all. The change in default happened when replaced the previous mechanism of calling THNN. Now I was about to submit a PR reverting the default to True, but the subtle twist is that TF uses False by default. avgpool2d is used in the wild, e.g. by ResNet. Should I change the docstring or should I change the default in Do you have an opinion ( maybe)? Best regards Thomas
So after submitting this, I saw that the module interface uses countincludepad=True all along, so the right option seems to be to have the same in the functional interface. I'll submit a PR.
we should indeed default functional interface to True as well. Thanks for the PR

Discussion:
- name: adaptive_max_pool3d(Tensor self, IntList[3] output_size) cname: VolumetricAdaptiveMaxPooling <del> - name: avg_pool2d(Tensor self, IntList[2] kernel_size, IntList[2] stride={}, IntList[2] padding=0, bool ceil_mode=false, bool count_include_pad=false) </del> <ins> - name: avg_pool2d(Tensor self, IntList[2] kernel_size, IntList[2] stride={}, IntList[2] padding=0, bool ceil_mode=false, bool count_include_pad=true) </ins> cname: SpatialAveragePooling default_init: stride: kernel_size <del> - name: avg_pool3d(Tensor self, IntList[3] kernel_size, IntList[3] stride={}, IntList[3] padding=0, bool ceil_mode=false, bool count_include_pad=false) </del> <ins> - name: avg_pool3d(Tensor self, IntList[3] kernel_size, IntList[3] stride={}, IntList[3] padding=0, bool ceil_mode=false, bool count_include_pad=true) </ins> cname: VolumetricAveragePooling default_init: stride: kernel_size
Change:
The only valid mode is 'bilinear', but one can pass anything to it and it will not complain:
Apparently, the is not passed to the backend function for . I think it should be removed.
Yes. I think the idea is that we'd like to support other modes at some point.

Discussion:
input2 = torch.randn(input_size, requires_grad=True) self.assertEqual(F.cosine_similarity(input1, input2, dim=1).size(), expected_size) <ins> 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') </ins> 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):

output (Tensor): output Tensor """ <ins> if mode != 'bilinear': raise NotImplementedError("nn.functional.grid_sample got unsupported mode: '{}'".format(mode)) </ins> return vision.grid_sampler(input, grid, padding_mode)
Change:
Steps to reproduce: a CI CUDA docker image, e.g.,  PyTorch, and run Expected result: It works Actual result: Workaround: set forces only one to be passed.
CC is this the nccl+sccache problem you were seeing?
cc has the exact error. CI log doesn't actually post the error.
sccache probably doesn't allow passing multiple right now, I can look into it if needed.
I am having this same error. How can you figure out which gencode to pass? I'm trying to build from source from a Dockerfile as well, as seen in this gist:
this is super helpful, thanks.
just wanted to make sure you saw that this is pulling from a ppc64le (IBM Power system) docker image, so you'll run into different issues if trying to build on an x64 machine.
I modified it very slightly for x64: It seems to build pytorch successfully for me (on latest master I suppose).
looking into this

Discussion:
include("${CMAKE_UTILS_PATH}") torch_cuda_get_nvcc_gencode_flag(NVCC_GENCODE) <del> string (REPLACE ";" " " NVCC_GENCODE "${NVCC_GENCODE}") string (REPLACE "-gencode " "-gencode=" NVCC_GENCODE "${NVCC_GENCODE}") </del> <ins> string(REPLACE "-gencode;" "-gencode=" NVCC_GENCODE "${NVCC_GENCODE}") </ins> message(STATUS "Set NVCC_GENCODE for building NCCL: ${NVCC_GENCODE}") ADD_CUSTOM_COMMAND(
Change:
Please check and fix all the PyTorch web links format from to , like in the official site.
closed via

Discussion:
def test_view(self): tensor = torch.rand(15) template = torch.rand(3, 5) <ins> empty = torch.Tensor() </ins> target = template.size().tolist() self.assertEqual(tensor.view_as(template).size().tolist(), target) self.assertEqual(tensor.view(3, 5).size().tolist(), target)

tensor_view = tensor.view(5, 3) tensor_view.fill_(random.uniform(0, 1)) self.assertEqual((tensor_view-tensor).abs().max(), 0) <ins> self.assertEqual(empty.view_as(empty), empty) self.assertEqual(empty.view(0), empty) </ins> def test_expand(self): result = torch.Tensor()

else: sizes = torch.LongStorage(args) sizes = _infer_sizes(sizes, self.nelement()) <del> if reduce(lambda a,b: a * b, sizes) != self.nelement(): raise RuntimeError('Invalid size for view. Input size: ' + 'x'.join(map(lambda v: str(v), self.size())) + ', output size: ' + 'x'.join(map(lambda v: str(v), sizes)) + '.') assert self.is_contiguous(), "expecting a contiguous tensor" dst.set_(self.storage(), self.storage_offset(), sizes) </del> <ins> numel = reduce(lambda a,b: a * b, sizes) if len(sizes) > 0 else 0 if numel != self.nelement(): def format_size(size): return 'x'.join(str(v) for v in size) if len(size) > 0 else '0' raise ValueError( "view of size '{0}' is invalid for input of size '{1}'" .format(format_size(sizes), format_size(self.size()))) if not self.is_contiguous(): raise ValueError("input should be contiguous") if self.storage() is not None: dst.set_(self.storage(), self.storage_offset(), sizes) </ins> return dst def view_as(self, tensor):
Change:
Dataloader call getitem as many times as indices in the current batch. In case datasets support a list of indices in one call, or a native python slice object, add a getbatch (optional) to pytorch dataset class. If dataloader sees the dataset has such a method implemented, make it fetch the batch corresping to the list of indices with one getbatch call rather than many getitem calls. This saves the trouble of calling getitem many times in cases where for example a disk file has to be opened then closed for every call and the underlying data structure supports a slicing or lists of indices for example hdf5 files.
will support something similar
is the latest version of this.

Discussion:
.. automethod:: fmod_ .. automethod:: frac .. automethod:: frac_ <del> .. automethod:: free </del> .. automethod:: gather .. automethod:: ge .. automethod:: ge_

.. automethod:: repeat .. automethod:: resize_ .. automethod:: resize_as_ <del> .. automethod:: retain </del> .. automethod:: round .. automethod:: round_ .. automethod:: rsqrt

]] [[ <del> name: free return: self arguments: - THTensor* self ]] [[ name: retain return: self arguments: - THTensor* self ]] [[ </del> python_name: index name: THPTensor_(getValue)<true> only_register: True