shrinath-suresh/blogs-docs-splitted huggingface dataset:
dtype: dtype = torch.int32
class torch.ShortStorage(*args, wrap_storage=None, dtype=None, device=None, _internal=False)
dtype: dtype = torch.int16
class torch.CharStorage(*args, wrap_storage=None, dtype=None, device=None, _internal=False)
dtype: dtype = torch.int8
class torch.ByteStorage(*args, wrap_storage=None, dtype=None, device=None, _internal=False)
dtype: dtype = torch.uint8
class torch.BoolStorage(*args, wrap_storage=None, dtype=None, device=None, _internal=False)
dtype: dtype = torch.bool
class torch.BFloat16Storage(*args, wrap_storage=None, dtype=None, device=None, _internal=False)
dtype: dtype = torch.bfloat16
class torch.ComplexDoubleStorage(*args, wrap_storage=None, dtype=None, device=None, _internal=False)
dtype: dtype = torch.complex128
class torch.ComplexFloatStorage(*args, wrap_storage=None, dtype=None, device=None, _internal=False)
dtype: dtype = torch.complex64
dtype: dtype = torch.complex64
class torch.QUInt8Storage(*args, wrap_storage=None, dtype=None, device=None, _internal=False)
dtype: dtype = torch.quint8
class torch.QInt8Storage(*args, wrap_storage=None, dtype=None, device=None, _internal=False)
dtype: dtype = torch.qint8
class torch.QInt32Storage(*args, wrap_storage=None, dtype=None, device=None, _internal=False)
dtype: dtype = torch.qint32
class torch.QUInt4x2Storage(*args, wrap_storage=None, dtype=None, device=None, _internal=False)
dtype: dtype = torch.quint4x2
class torch.QUInt2x4Storage(*args, wrap_storage=None, dtype=None, device=None, _internal=False)
dtype: dtype = torch.quint2x4
torch.monitor
Warning:
This module is a prototype release, and its interfaces and
  functionality may change without warning in future PyTorch releases.
"torch.monitor" provides an interface for logging events and counters
from PyTorch.
The stat interfaces are designed to be used for tracking high level
metrics that are periodically logged out to be used for monitoring
system performance. Since the stats aggregate with a specific window
size you can log to them from critical loops with minimal performance
impact.
For more infrequent events or values such as loss, accuracy, usage
tracking the event interface can be directly used.
Event handlers can be registered to handle the events and pass them to
an external event sink.
API Reference
class torch.monitor.Aggregation
  These are types of aggregations that can be used to accumulate
  stats.

Members:
  VALUE :
     VALUE returns the last value to be added.

  MEAN :
MEAN :
         MEAN computes the arithmetic mean of all the added values.
  COUNT :
     COUNT returns the total number of added values.

  SUM :
     SUM returns the sum of the added values.

  MAX :
     MAX returns the max of the added values.

  MIN :
     MIN returns the min of the added values.

property name
class torch.monitor.Stat
Stat is used to compute summary statistics in a performant way over
   fixed intervals. Stat logs the statistics as an Event once every
   "window_size" duration. When the window closes the stats are logged
   via the event handlers as a "torch.monitor.Stat" event.
"window_size" should be set to something relatively high to avoid a
   huge number of events being logged. Ex: 60s. Stat uses millisecond
   precision.
If "max_samples" is set, the stat will cap the number of samples
   per window by discarding add calls once "max_samples" adds have
   occurred. If it's not set, all "add" calls during the window will
be included. This is an optional field to make aggregations more
   directly comparable across windows when the number of samples might
   vary.
When the Stat is destructed it will log any remaining data even if
   the window hasn't elapsed.
init(self: torch._C._monitor.Stat, name: str, aggregations: List[torch._C._monitor.Aggregation], window_size: datetime.timedelta, max_samples: int = 9223372036854775807) -> None
  Constructs the "Stat".

add(self: torch._C._monitor.Stat, v: float) -> None
  Adds a value to the stat to be aggregated according to the
  configured stat type and aggregations.

property count
  Number of data points that have currently been collected. Resets
  once the event has been logged.

get(self: torch._C._monitor.Stat) -> Dict[torch._C._monitor.Aggregation, float]
  Returns the current value of the stat, primarily for testing
  purposes. If the stat has logged and no additional values have
  been added this will be zero.
been added this will be zero.
property name
  The name of the stat that was set during creation.

class torch.monitor.data_value_t
data_value_t is one of "str", "float", "int", "bool".
class torch.monitor.Event
Event represents a specific typed event to be logged. This can
   represent high-level data points such as loss or accuracy per epoch
   or more low-level aggregations such as through the Stats provided
   through this library.
All Events of the same type should have the same name so downstream
   handlers can correctly process them.
init(self: torch._C._monitor.Event, name: str, timestamp: datetime.datetime, data: Dict[str, data_value_t]) -> None
  Constructs the "Event".

property data
  The structured data contained within the "Event".

property name
  The name of the "Event".

property timestamp
  The timestamp when the "Event" happened.

class torch.monitor.EventHandlerHandle
EventHandlerHandle is a wrapper type returned by
"register_event_handler" used to unregister the handler via
   "unregister_event_handler". This cannot be directly initialized.
torch.monitor.log_event(event: torch._C._monitor.Event) -> None
log_event logs the specified event to all of the registered event
   handlers. It's up to the event handlers to log the event out to the
   corresponding event sink.
If there are no event handlers registered this method is a no-op.
torch.monitor.register_event_handler(callback: Callable[[torch._C._monitor.Event], None]) -> torch._C._monitor.EventHandlerHandle
register_event_handler registers a callback to be called whenever
   an event is logged via "log_event". These handlers should avoid
   blocking the main thread since that may interfere with training as
   they run during the "log_event" call.
torch.monitor.unregister_event_handler(handler: torch._C._monitor.EventHandlerHandle) -> None
unregister_event_handler unregisters the "EventHandlerHandle"
returned after calling "register_event_handler". After this returns
   the event handler will no longer receive events.
class torch.monitor.TensorboardEventHandler(writer)
TensorboardEventHandler is an event handler that will write known
   events to the provided SummaryWriter.
This currently only supports "torch.monitor.Stat" events which are
   logged as scalars.
-[ Example ]-



from torch.utils.tensorboard import SummaryWriter
from torch.monitor import TensorboardEventHandler, register_event_handler
writer = SummaryWriter("log_dir")
register_event_handler(TensorboardEventHandler(writer))



init(writer)
  Constructs the "TensorboardEventHandler".
C++
Note:
If you are looking for the PyTorch C++ API docs, directly go here.
PyTorch provides several features for working with C++, and itâs best
to choose from them based on your needs. At a high level, the
following support is available:
TorchScript C++ API
TorchScript allows PyTorch models defined in Python to be serialized
and then loaded and run in C++ capturing the model code via
compilation or tracing its execution. You can learn more in the
Loading a TorchScript Model in C++ tutorial. This means you can define
your models in Python as much as possible, but subsequently export
them via TorchScript for doing no-Python execution in production or
embedded environments. The TorchScript C++ API is used to interact
with these models and the TorchScript execution engine, including:


Loading serialized TorchScript models saved from Python


Doing simple model modifications if needed (e.g. pulling out
  submodules)
submodules)

Constructing the input and doing preprocessing using C++ Tensor API

Extending PyTorch and TorchScript with C++ Extensions
TorchScript can be augmented with user-supplied code through custom
operators and custom classes. Once registered with TorchScript, these
operators and classes can be invoked in TorchScript code run from
Python or from C++ as part of a serialized TorchScript model. The
Extending TorchScript with Custom C++ Operators tutorial walks through
interfacing TorchScript with OpenCV. In addition to wrapping a
function call with a custom operator, C++ classes and structs can be
bound into TorchScript through a pybind11-like interface which is
explained in the Extending TorchScript with Custom C++ Classes
tutorial.
Tensor and Autograd in C++
Most of the tensor and autograd operations in PyTorch Python API are
also available in the C++ API. These include:
also available in the C++ API. These include:


"torch::Tensor" methods such as "add" / "reshape" / "clone". For the
  full list of methods available, please see:
  https://pytorch.org/cppdocs/api/classat_1_1_tensor.html


C++ tensor indexing API that looks and behaves the same as the
  Python API. For details on its usage, please see:
  https://pytorch.org/cppdocs/notes/tensor_indexing.html


The tensor autograd APIs and the "torch::autograd" package that are
  crucial for building dynamic neural networks in C++ frontend. For
  more details, please see:
  https://pytorch.org/tutorials/advanced/cpp_autograd.html


Authoring Models in C++
The "author in TorchScript, infer in C++" workflow requires model
authoring to be done in TorchScript. However, there might be cases
where the model has to be authored in C++ (e.g. in workflows where a
Python component is undesirable). To serve such use cases, we provide
the full capability of authoring and training a neural net model
purely in C++, with familiar components such as "torch::nn" /
"torch::nn::functional" / "torch::optim" that closely resemble the
Python API.


For an overview of the PyTorch C++ model authoring and training API,
  please see: https://pytorch.org/cppdocs/frontend.html


For a detailed tutorial on how to use the API, please see:
  https://pytorch.org/tutorials/advanced/cpp_frontend.html


Docs for components such as "torch::nn" / "torch::nn::functional" /
  "torch::optim" can be found at:
  https://pytorch.org/cppdocs/api/library_root.html


Packaging for C++
For guidance on how to install and link with libtorch (the library
that contains all of the above C++ APIs), please see:
https://pytorch.org/cppdocs/installing.html. Note that on Linux there
are two types of libtorch binaries provided: one compiled with GCC
pre-cxx11 ABI and the other with GCC cxx11 ABI, and you should make
the selection based on the GCC ABI your system is using.
torch.random
torch.random.fork_rng(devices=None, enabled=True, _caller='fork_rng', _devices_kw='devices')
Forks the RNG, so that when you return, the RNG is reset to the
   state that it was previously in.
Parameters:
      * devices (iterable of CUDA IDs) -- CUDA devices for which
        to fork the RNG.  CPU RNG state is always forked.  By default,
        "fork_rng()" operates on all devices, but will emit a warning
        if your machine has a lot of devices, since this function will
        run very slowly in that case. If you explicitly specify
        devices, this warning will be suppressed
  * **enabled** (*bool*) -- if "False", the RNG is not forked.
    This is a convenience argument for easily disabling the
    context manager without having to delete it and unindent your
    Python code under it.

Return type:
      Generator
torch.random.get_rng_state()
Returns the random number generator state as a torch.ByteTensor.
Return type:
Return type:
      Tensor
torch.random.initial_seed()
Returns the initial seed for generating random numbers as a Python
   long.
Return type:
      int
torch.random.manual_seed(seed)
Sets the seed for generating random numbers. Returns a
   torch.Generator object.
Parameters:
      seed (int) -- The desired seed. Value must be within the
      inclusive range [-0x8000_0000_0000_0000,
      0xffff_ffff_ffff_ffff]. Otherwise, a RuntimeError is raised.
      Negative inputs are remapped to positive values with the formula
      0xffff_ffff_ffff_ffff + seed.
Return type:
      Generator
torch.random.seed()
Sets the seed for generating random numbers to a non-deterministic
   random number. Returns a 64 bit number used to seed the RNG.
Return type:
      int
torch.random.set_rng_state(new_state)
Sets the random number generator state.
Parameters:
      new_state (torch.ByteTensor) -- The desired state
AvgPool1d
class torch.nn.AvgPool1d(kernel_size, stride=None, padding=0, ceil_mode=False, count_include_pad=True)
Applies a 1D average pooling over an input signal composed of
   several input planes.
In the simplest case, the output value of the layer with input size
   (N, C, L), output (N, C, L_{out}) and "kernel_size" k can be
   precisely described as:
  \text{out}(N_i, C_j, l) = \frac{1}{k} \sum_{m=0}^{k-1}
  \text{input}(N_i, C_j, \text{stride} \times l + m)

If "padding" is non-zero, then the input is implicitly zero-padded
   on both sides for "padding" number of points.
Note:
 When ceil_mode=True, sliding windows are allowed to go off-bounds
 if they start within the left padding or the input. Sliding
 windows that would start in the right padded region are ignored.

The parameters "kernel_size", "stride", "padding" can each be an
   "int" or a one-element tuple.
Parameters:
      * kernel_size (Union[int, Tuple[int]]) --
the size of the window
  * **stride** (*Union**[**int**, **Tuple**[**int**]**]*) -- the
    stride of the window. Default value is "kernel_size"

  * **padding** (*Union**[**int**, **Tuple**[**int**]**]*) --
    implicit zero padding to be added on both sides

  * **ceil_mode** (*bool*) -- when True, will use *ceil* instead
    of *floor* to compute the output shape

  * **count_include_pad** (*bool*) -- when True, will include the
    zero-padding in the averaging calculation

Shape:
      * Input: (N, C, L_{in}) or (C, L_{in}).
  * Output: (N, C, L_{out}) or (C, L_{out}), where

       L_{out} = \left\lfloor \frac{L_{in} + 2 \times
       \text{padding} - \text{kernel\_size}}{\text{stride}} +
       1\right\rfloor

Examples:
  >>> # pool with window of size=3, stride=2
  >>> m = nn.AvgPool1d(3, stride=2)
  >>> m(torch.tensor([[[1., 2, 3, 4, 5, 6, 7]]]))
  tensor([[[2., 4., 6.]]])
torch.eq
torch.eq(input, other, *, out=None) -> Tensor
Computes element-wise equality
The second argument can be a number or a tensor whose shape is
   broadcastable with the first argument.
Parameters:
      * input (Tensor) -- the tensor to compare
  * **other** (*Tensor** or **float*) -- the tensor or value to
    compare

Keyword Arguments:
      out (Tensor, optional) -- the output tensor.
Returns:
      A boolean tensor that is True where "input" is equal to "other"
      and False elsewhere
Example:
  >>> torch.eq(torch.tensor([[1, 2], [3, 4]]), torch.tensor([[1, 1], [4, 4]]))
  tensor([[ True, False],
          [False, True]])
torch.floor
torch.floor(input, *, out=None) -> Tensor
Returns a new tensor with the floor of the elements of "input", the
   largest integer less than or equal to each element.
For integer inputs, follows the array-api convention of returning a
   copy of the input tensor.
  \text{out}_{i} = \left\lfloor \text{input}_{i} \right\rfloor

Parameters:
      input (Tensor) -- the input tensor.
Keyword Arguments:
      out (Tensor, optional) -- the output tensor.
Example:
  >>> a = torch.randn(4)
  >>> a
  tensor([-0.8166,  1.5308, -0.2530, -0.2091])
  >>> torch.floor(a)
  tensor([-1.,  1., -1., -1.])
torch.autograd.Function.jvp
static Function.jvp(ctx, *grad_inputs)
Defines a formula for differentiating the operation with forward
   mode automatic differentiation. This function is to be overridden
   by all subclasses. It must accept a context "ctx" as the first
   argument, followed by as many inputs as the "forward()" got (None
   will be passed in for non tensor inputs of the forward function),
   and it should return as many tensors as there were outputs to
   "forward()". Each argument is the gradient w.r.t the given input,
   and each returned value should be the gradient w.r.t. the
   corresponding output. If an output is not a Tensor or the function
   is not differentiable with respect to that output, you can just
   pass None as a gradient for that input.
You can use the "ctx" object to pass any value from the forward to
   this functions.
Return type:
      Any
ConvReLU3d
class torch.ao.nn.intrinsic.quantized.ConvReLU3d(in_channels, out_channels, kernel_size, stride=1, padding=0, dilation=1, groups=1, bias=True, padding_mode='zeros', device=None, dtype=None)
A ConvReLU3d module is a fused module of Conv3d and ReLU
We adopt the same interface as "torch.ao.nn.quantized.Conv3d".
Attributes: Same as torch.ao.nn.quantized.Conv3d
torch.Tensor.tolist
Tensor.tolist() -> list or number
Returns the tensor as a (nested) list. For scalars, a standard
   Python number is returned, just like with "item()". Tensors are
   automatically moved to the CPU first if necessary.
This operation is not differentiable.
Examples:
  >>> a = torch.randn(2, 2)
  >>> a.tolist()
  [[0.012766935862600803, 0.5415473580360413],
   [-0.08909505605697632, 0.7729271650314331]]
  >>> a[0,0].tolist()
  0.012766935862600803
torch.autograd.gradgradcheck
torch.autograd.gradgradcheck(func, inputs, grad_outputs=None, *, eps=1e-06, atol=1e-05, rtol=0.001, gen_non_contig_grad_outputs=False, raise_exception=True, nondet_tol=0.0, check_undefined_grad=True, check_grad_dtypes=False, check_batched_grad=False, check_fwd_over_rev=False, check_rev_over_rev=True, fast_mode=False)
Check gradients of gradients computed via small finite differences
   against analytical gradients w.r.t. tensors in "inputs" and
   "grad_outputs" that are of floating point or complex type and with
   "requires_grad=True".
This function checks that backpropagating through the gradients
   computed to the given "grad_outputs" are correct.
The check between numerical and analytical gradients uses
   "allclose()".
Note:
 The default values are designed for "input" and "grad_outputs" of
 double precision. This check will likely fail if they are of less
 precision, e.g., "FloatTensor".

Warning:
precision, e.g., "FloatTensor".
Warning:
 If any checked tensor in "input" and "grad_outputs" has
 overlapping memory, i.e., different indices pointing to the same
 memory address (e.g., from "torch.expand()"), this check will
 likely fail because the numerical gradients computed by point
 perturbation at such indices will change values at all other
 indices that share the same memory address.

Parameters:
      * func (function) -- a Python function that takes Tensor
        inputs and returns a Tensor or a tuple of Tensors
  * **inputs** (*tuple of Tensor** or **Tensor*) -- inputs to the
    function

  * **grad_outputs** (*tuple of Tensor** or **Tensor**,
    **optional*) -- The gradients with respect to the function's
    outputs.

  * **eps** (*float**, **optional*) -- perturbation for finite
    differences

  * **atol** (*float**, **optional*) -- absolute tolerance

  * **rtol** (*float**, **optional*) -- relative tolerance
gen_non_contig_grad_outputs (bool, optional) -- if
        "grad_outputs" is "None" and "gen_non_contig_grad_outputs" is
        "True", the randomly generated gradient outputs are made to be
        noncontiguous


raise_exception (bool, optional) -- indicating
    whether to raise an exception if the check fails. The
    exception gives more information about the exact nature of the
    failure. This is helpful when debugging gradchecks.


nondet_tol (float, optional) -- tolerance for non-
    determinism. When running identical inputs through the
    differentiation, the results must either match exactly
    (default, 0.0) or be within this tolerance. Note that a small
    amount of nondeterminism in the gradient will lead to larger
    inaccuracies in the second derivative.


check_undefined_grad (bool, optional) -- if True,
    check if undefined output grads are supported and treated as
zeros
  * **check_batched_grad** (*bool**, **optional*) -- if True,
    check if we can compute batched gradients using prototype vmap
    support. Defaults to False.

  * **fast_mode** (*bool**, **optional*) -- if True, run a faster
    implementation of gradgradcheck that no longer computes the
    entire jacobian.

Returns:
      True if all differences satisfy allclose condition
Return type:
      bool
torch.jit.trace
torch.jit.trace(func, example_inputs=None, optimize=None, check_trace=True, check_inputs=None, check_tolerance=1e-05, strict=True, _force_outplace=False, _module_class=None, _compilation_unit=, example_kwarg_inputs=None)
Trace a function and return an executable  or "ScriptFunction" that
   will be optimized using just-in-time compilation. Tracing is ideal
   for code that operates only on "Tensor"s and lists, dictionaries,
   and tuples of "Tensor"s.
Using torch.jit.trace and torch.jit.trace_module, you can turn
   an existing module or Python function into a TorchScript
   "ScriptFunction" or "ScriptModule". You must provide example
   inputs, and we run the function, recording the operations performed
   on all the tensors.


The resulting recording of a standalone function produces
     ScriptFunction.


The resulting recording of nn.Module.forward or nn.Module
     produces ScriptModule.
produces ScriptModule.
This module also contains any parameters that the original module
   had as well.
Warning:
 Tracing only correctly records functions and modules which are
 not data dependent (e.g., do not have conditionals on data in
 tensors) and do not have any untracked external dependencies
 (e.g., perform input/output or access global variables). Tracing
 only records operations done when the given function is run on
 the given tensors. Therefore, the returned *ScriptModule* will
 always run the same traced graph on any input. This has some
 important implications when your module is expected to run
 different sets of operations, depending on the input and/or the
 module state. For example,

 * Tracing will not record any control-flow like if-statements or
   loops. When this control-flow is constant across your module,
   this is fine and it often inlines the control-flow decisions.
But sometimes the control-flow is actually part of the model
       itself. For instance, a recurrent network is a loop over the
       (possibly dynamic) length of an input sequence.
 * In the returned "ScriptModule", operations that have different
   behaviors in "training" and "eval" modes will always behave as
   if it is in the mode it was in during tracing, no matter which
   mode the *ScriptModule* is in.

 In cases like these, tracing would not be appropriate and
 "scripting" is a better choice. If you trace such models, you may
 silently get incorrect results on subsequent invocations of the
 model. The tracer will try to emit warnings when doing something
 that may cause an incorrect trace to be produced.

Parameters:
      func (callable or torch.nn.Module) -- A Python
      function or torch.nn.Module that will be run with
      example_inputs. func arguments and return values  must be
tensors or (possibly nested) tuples that contain tensors. When a
      module is passed torch.jit.trace, only the "forward" method is
      run and traced (see "torch.jit.trace" for details).
Keyword Arguments:
      * example_inputs (tuple or torch.Tensor or None,
        optional) -- A tuple of example inputs that will be passed
        to the function while tracing. Default: "None". Either this
        argument or "example_kwarg_inputs" should be specified. The
        resulting trace can be run with inputs of different types and
        shapes assuming the traced operations support those types and
        shapes. example_inputs may also be a single Tensor in which
        case it is automatically wrapped in a tuple. When the value is
        None, "example_kwarg_inputs" should be specified.
  * **check_trace** ("bool", optional) -- Check if the same inputs
    run through traced code produce the same outputs. Default: