pytorch · ericnakagawa · Sep 18, 2018 · Sep 18, 2018 · Sep 18, 2018 · Sep 18, 2018
diff --git a/.DS_Store b/.DS_Store
diff --git a/docs/.DS_Store b/docs/.DS_Store
diff --git a/docs/0.1.12/.buildinfo b/docs/0.1.12/.buildinfo
@@ -0,0 +1,4 @@
+# Sphinx build info version 1
+# This file hashes the configuration used when building these files. When it is not found, a full rebuild will be done.
+config: e3c0334253ce75f93e455219de7c5075
+tags: 645f666f9bcd5a90fca523b33c5a78b7
diff --git a/docs/0.1.12/_modules/index.html b/docs/0.1.12/_modules/index.html
diff --git a/docs/0.1.12/_modules/torch.html b/docs/0.1.12/_modules/torch.html
diff --git a/docs/0.1.12/_modules/torch/_tensor_str.html b/docs/0.1.12/_modules/torch/_tensor_str.html
diff --git a/docs/0.1.12/_modules/torch/_utils.html b/docs/0.1.12/_modules/torch/_utils.html
diff --git a/docs/0.1.12/_modules/torch/autograd.html b/docs/0.1.12/_modules/torch/autograd.html
diff --git a/docs/0.1.12/_modules/torch/autograd/function.html b/docs/0.1.12/_modules/torch/autograd/function.html
diff --git a/docs/0.1.12/_modules/torch/autograd/variable.html b/docs/0.1.12/_modules/torch/autograd/variable.html
diff --git a/docs/0.1.12/_modules/torch/cuda.html b/docs/0.1.12/_modules/torch/cuda.html
diff --git a/docs/0.1.12/_modules/torch/cuda/comm.html b/docs/0.1.12/_modules/torch/cuda/comm.html
diff --git a/docs/0.1.12/_modules/torch/cuda/streams.html b/docs/0.1.12/_modules/torch/cuda/streams.html
diff --git a/docs/0.1.12/_modules/torch/functional.html b/docs/0.1.12/_modules/torch/functional.html
diff --git a/docs/0.1.12/_modules/torch/multiprocessing.html b/docs/0.1.12/_modules/torch/multiprocessing.html
diff --git a/docs/0.1.12/_modules/torch/nn/functional.html b/docs/0.1.12/_modules/torch/nn/functional.html
diff --git a/docs/0.1.12/_modules/torch/nn/init.html b/docs/0.1.12/_modules/torch/nn/init.html
diff --git a/docs/0.1.12/_modules/torch/nn/modules/activation.html b/docs/0.1.12/_modules/torch/nn/modules/activation.html
diff --git a/docs/0.1.12/_modules/torch/nn/modules/batchnorm.html b/docs/0.1.12/_modules/torch/nn/modules/batchnorm.html
diff --git a/docs/0.1.12/_modules/torch/nn/modules/container.html b/docs/0.1.12/_modules/torch/nn/modules/container.html
diff --git a/docs/0.1.12/_modules/torch/nn/modules/conv.html b/docs/0.1.12/_modules/torch/nn/modules/conv.html
diff --git a/docs/0.1.12/_modules/torch/nn/modules/distance.html b/docs/0.1.12/_modules/torch/nn/modules/distance.html
diff --git a/docs/0.1.12/_modules/torch/nn/modules/dropout.html b/docs/0.1.12/_modules/torch/nn/modules/dropout.html
diff --git a/docs/0.1.12/_modules/torch/nn/modules/instancenorm.html b/docs/0.1.12/_modules/torch/nn/modules/instancenorm.html
diff --git a/docs/0.1.12/_modules/torch/nn/modules/linear.html b/docs/0.1.12/_modules/torch/nn/modules/linear.html
diff --git a/docs/0.1.12/_modules/torch/nn/modules/loss.html b/docs/0.1.12/_modules/torch/nn/modules/loss.html
diff --git a/docs/0.1.12/_modules/torch/nn/modules/module.html b/docs/0.1.12/_modules/torch/nn/modules/module.html
diff --git a/docs/0.1.12/_modules/torch/nn/modules/pixelshuffle.html b/docs/0.1.12/_modules/torch/nn/modules/pixelshuffle.html
diff --git a/docs/0.1.12/_modules/torch/nn/modules/pooling.html b/docs/0.1.12/_modules/torch/nn/modules/pooling.html
diff --git a/docs/0.1.12/_modules/torch/nn/modules/rnn.html b/docs/0.1.12/_modules/torch/nn/modules/rnn.html
diff --git a/docs/0.1.12/_modules/torch/nn/modules/sparse.html b/docs/0.1.12/_modules/torch/nn/modules/sparse.html
diff --git a/docs/0.1.12/_modules/torch/nn/modules/upsampling.html b/docs/0.1.12/_modules/torch/nn/modules/upsampling.html
diff --git a/docs/0.1.12/_modules/torch/nn/parallel/data_parallel.html b/docs/0.1.12/_modules/torch/nn/parallel/data_parallel.html
diff --git a/docs/0.1.12/_modules/torch/nn/parameter.html b/docs/0.1.12/_modules/torch/nn/parameter.html
diff --git a/docs/0.1.12/_modules/torch/nn/utils/clip_grad.html b/docs/0.1.12/_modules/torch/nn/utils/clip_grad.html
diff --git a/docs/0.1.12/_modules/torch/nn/utils/rnn.html b/docs/0.1.12/_modules/torch/nn/utils/rnn.html
diff --git a/docs/0.1.12/_modules/torch/optim/adadelta.html b/docs/0.1.12/_modules/torch/optim/adadelta.html
diff --git a/docs/0.1.12/_modules/torch/optim/adagrad.html b/docs/0.1.12/_modules/torch/optim/adagrad.html
diff --git a/docs/0.1.12/_modules/torch/optim/adam.html b/docs/0.1.12/_modules/torch/optim/adam.html
diff --git a/docs/0.1.12/_modules/torch/optim/adamax.html b/docs/0.1.12/_modules/torch/optim/adamax.html
diff --git a/docs/0.1.12/_modules/torch/optim/asgd.html b/docs/0.1.12/_modules/torch/optim/asgd.html
diff --git a/docs/0.1.12/_modules/torch/optim/lbfgs.html b/docs/0.1.12/_modules/torch/optim/lbfgs.html
diff --git a/docs/0.1.12/_modules/torch/optim/optimizer.html b/docs/0.1.12/_modules/torch/optim/optimizer.html
diff --git a/docs/0.1.12/_modules/torch/optim/rmsprop.html b/docs/0.1.12/_modules/torch/optim/rmsprop.html
diff --git a/docs/0.1.12/_modules/torch/optim/rprop.html b/docs/0.1.12/_modules/torch/optim/rprop.html
diff --git a/docs/0.1.12/_modules/torch/optim/sgd.html b/docs/0.1.12/_modules/torch/optim/sgd.html
diff --git a/docs/0.1.12/_modules/torch/serialization.html b/docs/0.1.12/_modules/torch/serialization.html
diff --git a/docs/0.1.12/_modules/torch/sparse.html b/docs/0.1.12/_modules/torch/sparse.html
diff --git a/docs/0.1.12/_modules/torch/storage.html b/docs/0.1.12/_modules/torch/storage.html
diff --git a/docs/0.1.12/_modules/torch/tensor.html b/docs/0.1.12/_modules/torch/tensor.html
diff --git a/docs/0.1.12/_modules/torch/utils/data/dataloader.html b/docs/0.1.12/_modules/torch/utils/data/dataloader.html
diff --git a/docs/0.1.12/_modules/torch/utils/data/dataset.html b/docs/0.1.12/_modules/torch/utils/data/dataset.html
diff --git a/docs/0.1.12/_modules/torch/utils/data/sampler.html b/docs/0.1.12/_modules/torch/utils/data/sampler.html
diff --git a/docs/0.1.12/_modules/torch/utils/ffi.html b/docs/0.1.12/_modules/torch/utils/ffi.html
diff --git a/docs/0.1.12/_modules/torch/utils/model_zoo.html b/docs/0.1.12/_modules/torch/utils/model_zoo.html
diff --git a/docs/0.1.12/_sources/autograd.rst.txt b/docs/0.1.12/_sources/autograd.rst.txt
@@ -0,0 +1,53 @@
+.. role:: hidden
+    :class: hidden-section
+
+Automatic differentiation package - torch.autograd
+==================================================
+
+.. automodule:: torch.autograd
+.. currentmodule:: torch.autograd
+
+.. autofunction:: backward
+
+Variable
+--------
+
+API compatibility
+^^^^^^^^^^^^^^^^^
+
+Variable API is nearly the same as regular Tensor API (with the exception
+of a couple in-place methods, that would overwrite inputs required for
+gradient computation). In most cases Tensors can be safely replaced with
+Variables and the code will remain to work just fine. Because of this,
+we're not documenting all the operations on variables, and you should
+refer to :class:`torch.Tensor` docs for this purpose.
+
+In-place operations on Variables
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Supporting in-place operations in autograd is a hard matter, and we discourage
+their use in most cases. Autograd's aggressive buffer freeing and reuse makes
+it very efficient and there are very few occasions when in-place operations
+actually lower memory usage by any significant amount. Unless you're operating
+under heavy memory pressure, you might never need to use them.
+
+In-place correctness checks
+^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+All :class:`Variable` s keep track of in-place operations applied to them, and
+if the implementation detects that a variable was saved for backward in one of
+the functions, but it was modified in-place afterwards, an error will be raised
+once backward pass is started. This ensures that if you're using in-place
+functions and not seing any errors, you can be sure that the computed gradients
+are correct.
+
+
+.. autoclass:: Variable
+    :members:
+
+:hidden:`Function`
+------------------
+
+.. autoclass:: Function
+    :members:
+
diff --git a/docs/0.1.12/_sources/cuda.rst.txt b/docs/0.1.12/_sources/cuda.rst.txt
@@ -0,0 +1,27 @@
+torch.cuda
+===================================
+
+.. currentmodule:: torch.cuda
+
+.. automodule:: torch.cuda
+   :members:
+
+Communication collectives
+-------------------------
+
+.. autofunction:: torch.cuda.comm.broadcast
+
+.. autofunction:: torch.cuda.comm.reduce_add
+
+.. autofunction:: torch.cuda.comm.scatter
+
+.. autofunction:: torch.cuda.comm.gather
+
+Streams and events
+------------------
+
+.. autoclass:: Stream
+   :members:
+
+.. autoclass:: Event
+   :members:
diff --git a/docs/0.1.12/_sources/data.rst.txt b/docs/0.1.12/_sources/data.rst.txt
@@ -0,0 +1,12 @@
+torch.utils.data
+===================================
+
+.. automodule:: torch.utils.data
+.. autoclass:: Dataset
+.. autoclass:: TensorDataset
+.. autoclass:: DataLoader
+.. autoclass:: torch.utils.data.sampler.Sampler
+.. autoclass:: torch.utils.data.sampler.SequentialSampler
+.. autoclass:: torch.utils.data.sampler.RandomSampler
+.. autoclass:: torch.utils.data.sampler.SubsetRandomSampler
+.. autoclass:: torch.utils.data.sampler.WeightedRandomSampler
diff --git a/docs/0.1.12/_sources/ffi.rst.txt b/docs/0.1.12/_sources/ffi.rst.txt
@@ -0,0 +1,6 @@
+torch.utils.ffi
+===============
+
+.. currentmodule:: torch.utils.ffi
+.. autofunction:: create_extension
+
diff --git a/docs/0.1.12/_sources/index.rst.txt b/docs/0.1.12/_sources/index.rst.txt
@@ -0,0 +1,55 @@
+.. PyTorch documentation master file, created by
+   sphinx-quickstart on Fri Dec 23 13:31:47 2016.
+   You can adapt this file completely to your liking, but it should at least
+   contain the root `toctree` directive.
+
+:github_url: https://github.com/pytorch/pytorch
+
+PyTorch documentation
+===================================
+
+PyTorch is an optimized tensor library for deep learning using GPUs and CPUs.
+
+.. toctree::
+   :glob:
+   :maxdepth: 1
+   :caption: Notes
+
+   notes/*
+
+
+.. toctree::
+   :maxdepth: 1
+   :caption: Package Reference
+
+   torch
+   tensors
+   sparse
+   storage
+   nn
+   optim
+   torch.autograd <autograd>
+   torch.multiprocessing <multiprocessing>
+   torch.legacy <legacy>
+   cuda
+   ffi
+   data
+   model_zoo
+
+.. toctree::
+   :glob:
+   :maxdepth: 1
+   :caption: torchvision Reference
+
+   torchvision/torchvision
+   torchvision/datasets
+   torchvision/models
+   torchvision/transforms
+   torchvision/utils
+
+
+Indices and tables
+==================
+
+* :ref:`genindex`
+* :ref:`modindex`
diff --git a/docs/0.1.12/_sources/legacy.rst.txt b/docs/0.1.12/_sources/legacy.rst.txt
@@ -0,0 +1,4 @@
+Legacy package - torch.legacy
+===================================
+
+.. automodule:: torch.legacy
diff --git a/docs/0.1.12/_sources/model_zoo.rst.txt b/docs/0.1.12/_sources/model_zoo.rst.txt
@@ -0,0 +1,5 @@
+torch.utils.model_zoo
+===================================
+
+.. automodule:: torch.utils.model_zoo
+.. autofunction:: load_url
diff --git a/docs/0.1.12/_sources/multiprocessing.rst.txt b/docs/0.1.12/_sources/multiprocessing.rst.txt
@@ -0,0 +1,88 @@
+Multiprocessing package - torch.multiprocessing
+===============================================
+
+.. automodule:: torch.multiprocessing
+.. currentmodule:: torch.multiprocessing
+
+.. warning::
+
+    If the main process exits abruptly (e.g. because of an incoming signal),
+    Python's ``multiprocessing`` sometimes fails to clean up its children.
+    It's a known caveat, so if you're seeing any resource leaks after
+    interrupting the interpreter, it probably means that this has just happened
+    to you.
+
+Strategy management
+-------------------
+
+.. autofunction:: get_all_sharing_strategies
+.. autofunction:: get_sharing_strategy
+.. autofunction:: set_sharing_strategy
+
+Sharing CUDA tensors
+--------------------
+
+Sharing CUDA tensors between processes is supported only in Python 3, using
+a ``spawn`` or ``forkserver`` start methods. :mod:`python:multiprocessing` in
+Python 2 can only create subprocesses using ``fork``, and it's not supported
+by the CUDA runtime.
+
+.. warning::
+
+    CUDA API requires that the allocation exported to other processes remains
+    valid as long as it's used by them. You should be careful and ensure that
+    CUDA tensors you shared don't go out of scope as long as it's necessary.
+    This shouldn't be a problem for sharing model parameters, but passing other
+    kinds of data should be done with care. Note that this restriction doesn't
+    apply to shared CPU memory.
+
+
+Sharing strategies
+------------------
+
+This section provides a brief overview into how different sharing strategies
+work. Note that it applies only to CPU tensor - CUDA tensors will always use
+the CUDA API, as that's the only way they can be shared.
+
+File descriptor - ``file_descriptor``
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+
+.. note::
+
+    This is the default strategy (except for macOS and OS X where it's not
+    supported).
+
+This strategy will use file descriptors as shared memory handles. Whenever a
+storage is moved to shared memory, a file descriptor obtained from ``shm_open``
+is cached with the object, and when it's going to be sent to other processes,
+the file descriptor will be transferred (e.g. via UNIX sockets) to it. The
+receiver will also cache the file descriptor and ``mmap`` it, to obtain a shared
+view onto the storage data.
+
+Note that if there will be a lot of tensors shared, this strategy will keep a
+large number of file descriptors open most of the time. If your system has low
+limits for the number of open file descriptors, and you can't rise them, you
+should use the ``file_system`` strategy.
+
+File system - ``file_system``
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+This strategy will use file names given to ``shm_open`` to identify the shared
+memory regions. This has a benefit of not requiring the implementation to cache
+the file descriptors obtained from it, but at the same time is prone to shared
+memory leaks. The file can't be deleted right after its creation, because other
+processes need to access it to open their views. If the processes fatally
+crash, or are killed, and don't call the storage destructors, the files will
+remain in the system. This is very serious, because they keep using up the
+memory until the system is restarted, or they're freed manually.
+
+To counter the problem of shared memory file leaks, :mod:`torch.multiprocessing`
+will spawn a daemon named ``torch_shm_manager`` that will isolate itself from
+the current process group, and will keep track of all shared memory allocations.
+Once all processes connected to it exit, it will wait a moment to ensure there
+will be no new connections, and will iterate over all shared memory files
+allocated by the group. If it finds that any of them still exist, they will be
+deallocated. We've tested this method and it prooved to be robust to various
+failures. Still, if your system has high enough limits, and ``file_descriptor``
+is a supported strategy, we do not recommend switching to this one.