[BE] Fix some typos (#2811)

Author: antoinebrl

docs/source/reference/collectors.rst

@@ -155,7 +155,7 @@ will work:
     >>> collector = SyncDataCollector(env, policy, frames_per_batch=N, total_frames=-1)
     >>> for data in collector:
     ...     memory.extend(data)
-    >>> # MultiSyncDataCollector + regular env: behaves like a ParallelEnv iif cat_results="stack"
+    >>> # MultiSyncDataCollector + regular env: behaves like a ParallelEnv if cat_results="stack"
     >>> memory = ReplayBuffer(
     ...     storage=LazyTensorStorage(N, ndim=2),
     ...     sampler=SliceSampler(num_slices=4, trajectory_key=("collector", "traj_ids"))

docs/source/reference/data.rst

@@ -930,7 +930,7 @@ It is important that your environment specs match the input and output that it s
 :class:`~torchrl.envs.ParallelEnv` will create buffers from these specs to communicate with the spawn processes.
 Check the :func:`torchrl.envs.utils.check_env_specs` method for a sanity check.
 
-If needed, specs can be automatially generated from data using the :func:`~torchrl.envs.utils.make_composite_from_td`
+If needed, specs can be automatically generated from data using the :func:`~torchrl.envs.utils.make_composite_from_td`
 function.
 
 Specs fall in two main categories, numerical and categorical.
@@ -1073,7 +1073,7 @@ Then, a second storage keeps track of the actions and results associated with th
     >>> next_data = forest.data_map[index]
 
 The ``next_data`` entry can have any shape, but it will usually match the shape of ``index`` (since at each index
-corresponds one action). Once ``next_data`` is obtrained, it can be put together with ``data`` to form a set of nodes,
+corresponds one action). Once ``next_data`` is obtained, it can be put together with ``data`` to form a set of nodes,
 and the tree can be expanded for each of these. The following figure shows how this is done.
 
 .. figure:: /_static/img/collector-copy.png

docs/source/reference/envs.rst

@@ -301,7 +301,7 @@ The ``"_reset"`` key has two distinct functionalities:
    Designing an environment that behaves according to ``"_reset"`` inputs is the
    developer's responsibility, as TorchRL has no control over the inner logic
    of :meth:`~.EnvBase._reset`. Nevertheless, the following point should be
-   kept in mind when desiging that method.
+   kept in mind when designing that method.
 
 2. After a call to :meth:`~.EnvBase._reset`, the output will be masked with the
    ``"_reset"`` entries and the output of the previous :meth:`~.EnvBase.step`
@@ -329,7 +329,7 @@ designing reset functionalities:
   whether the ``"_reset"`` at the root level corresponds to an ``all()``, ``any()``
   or custom call to the nested ``"done"`` entries cannot be known in advance,
   and it is explicitly assumed that the ``"_reset"`` at the root was placed
-  there to superseed the nested values (for an example, have a look at
+  there to supersede the nested values (for an example, have a look at
   :class:`~.PettingZooWrapper` implementation where each group has one or more
   ``"done"`` entries associated which is aggregated at the root level with a
   ``any`` or ``all`` logic depending on the task).
@@ -1126,7 +1126,7 @@ to always know what the latest available actions are. You can do this like so:
         >>> )
 
 .. note::
-  In case you are using a parallel environment it is important to add the transform to the parallel enviornment itself
+  In case you are using a parallel environment it is important to add the transform to the parallel environment itself
   and not to its sub-environments.
 
 

docs/source/reference/trainers.rst

@@ -9,7 +9,7 @@ The trainer package provides utilities to write re-usable training scripts. The
 trainer that implements a nested loop, where the outer loop runs the data collection steps and the inner
 loop the optimization steps. We believe this fits multiple RL training schemes, such as
 on-policy, off-policy, model-based and model-free solutions, offline RL and others.
-More particular cases, such as meta-RL algorithms may have training schemes that differ substentially.
+More particular cases, such as meta-RL algorithms may have training schemes that differ substantially.
 
 The ``trainer.train()`` method can be sketched as follows:
 

examples/distributed/replay_buffers/distributed_replay_buffer.py

@@ -3,7 +3,7 @@
 ===========================
 
 This example illustrates how a skeleton reinforcement learning algorithm can be implemented in a distributed fashion with communication between nodes/workers handled using `torch.rpc`.
-It focusses on how to set up a replay buffer worker that accepts remote operation requests efficiently, and so omits any learning component such as parameter updates that may be required for a complete distributed reinforcement learning algorithm implementation.
+It focuses on how to set up a replay buffer worker that accepts remote operation requests efficiently, and so omits any learning component such as parameter updates that may be required for a complete distributed reinforcement learning algorithm implementation.
 In this model, >= 1 data collectors workers are responsible for collecting experiences in an environment, the replay buffer worker receives all of these experiences and exposes them to a trainer that is responsible for making parameter updates to any required models.
 """
 
@@ -150,7 +150,7 @@ def _create_and_launch_data_collectors(self) -> None:
 
 class ReplayBufferNode(RemoteTensorDictReplayBuffer):
     """Experience replay buffer node that is capable of accepting remote connections. Being a `RemoteTensorDictReplayBuffer`
-    means all of its public methods are remotely invokable using `torch.rpc`.
+    means all of its public methods are remotely invocable using `torch.rpc`.
     Using a LazyMemmapStorage is highly advised in distributed settings with shared storage due to the lower serialization
     cost of MemoryMappedTensors as well as the ability to specify file storage locations which can improve ability to recover from node failures.
 

knowledge_base/MUJOCO_INSTALLATION.md

@@ -189,7 +189,7 @@ issues when running `import mujoco_py` and some troubleshooting for each of them
     /path/to/conda/envs/mj_envs/lib/python3.8/site-packages/glfw/__init__.py:912: GLFWError: (65537) b'The GLFW library is not initialized'
     ```
 
-    _Solution_: This can usually be sovled by setting EGL as your mujoco_gl backend: `MUJOCO_GL=egl python myscript.py`
+    _Solution_: This can usually be solved by setting EGL as your mujoco_gl backend: `MUJOCO_GL=egl python myscript.py`
 
 
 
@@ -208,7 +208,7 @@ RuntimeError: Failed to initialize OpenGL
 > Mujoco's EGL code indexes devices globally while CUDA_VISIBLE_DEVICES 
   (when used with job schedulers like slurm) returns the local device ids. 
   This can be worked around by setting the `GPUS` environment variable to the 
-  global device id. For slurm, it can be obtained using `SLURM_STEP_GPUS` enviroment variable.
+  global device id. For slurm, it can be obtained using `SLURM_STEP_GPUS` environment variable.
 
 8. Rendered images are completely black.
 

knowledge_base/PRO-TIPS.md

@@ -76,7 +76,7 @@ Errors to look for that may be related to this misconception are the following:
   than the number of environments you're working with (twice as much for instance). This
   is also and especially true for environments that are rendered (even if they are rendered on GPU). 
 - The speed of training depends upon several factors and there is not a one-fits-all
-  solution to every problem. The common bottlnecks are:
+  solution to every problem. The common bottlenecks are:
   - **data collection**: the simulator speed may affect performance, as can the data
     transformation that follows. Speeding up environment interactions is usually
     done via vectorization (if the simulators enables it, e.g. Brax and other Jax-based
@@ -93,7 +93,7 @@ Errors to look for that may be related to this misconception are the following:
     a computational bottleneck as these are usually coded using plain for loops.
     If profiling indicates that this operation is taking a considerable amount
     of time, consider using our fully vectorized solutions instead.
-  - **Loss compuation**: The loss computation and the optimization
+  - **Loss computation**: The loss computation and the optimization
     steps are frequently responsible of a significant share of the compute time.
     Some techniques can speed things up. For instance, if multiple target networks
     are being used, using vectorized maps and functional programming (through 

knowledge_base/VERSIONING_ISSUES.md

@@ -7,7 +7,7 @@ ImportError: /usr/local/lib/python3.7/dist-packages/torchrl/_torchrl.so: undefin
 ```
 
 ### How to reproduce
-1. Create an Colab Notebook (at 24/11/2022 Colab enviroment has Python 3.7 and Pytorch 1.12 installed by default).
+1. Create an Colab Notebook (at 24/11/2022 Colab environment has Python 3.7 and Pytorch 1.12 installed by default).
 2. ``` !pip install torchrl ```
 3. ``` import torchrl ```
 
@@ -20,4 +20,4 @@ before the ```!pip install torchrl``` command. This will install the latest pyto
 ### Workarounds
 There are two workarounds to this issue
 1. Install/upgrade to the latest pytorch release before installing torchrl.
-2. If you need to use a previous pytorch relase: Install functorch version related to your torch distribution: e.g. ``` pip install functorch==0.2.0 ``` and install library from source ``` pip install git+https://github.com/pytorch/rl@<lib_version_here> ```.
+2. If you need to use a previous pytorch release: Install functorch version related to your torch distribution: e.g. ``` pip install functorch==0.2.0 ``` and install library from source ``` pip install git+https://github.com/pytorch/rl@<lib_version_here> ```.

sota-implementations/decision_transformer/lamb.py

@@ -85,7 +85,7 @@ def step(self, closure=None):
                 grad = p.grad
                 if grad.is_sparse:
                     raise RuntimeError(
-                        "Lamb does not support sparse gradients, consider SparseAdam instad."
+                        "Lamb does not support sparse gradients, consider SparseAdam instead."
                     )
                 global_grad_norm.add_(grad.pow(2).sum())
 

sota-implementations/redq/utils.py

@@ -108,7 +108,7 @@
 def correct_for_frame_skip(cfg: "DictConfig") -> "DictConfig":  # noqa: F821
     """Correct the arguments for the input frame_skip, by dividing all the arguments that reflect a count of frames by the frame_skip.
 
-    This is aimed at avoiding unknowingly over-sampling from the environment, i.e. targetting a total number of frames
+    This is aimed at avoiding unknowingly over-sampling from the environment, i.e. targeting a total number of frames
     of 1M but actually collecting frame_skip * 1M frames.
 
     Args:
@@ -578,7 +578,7 @@ def transformed_env_constructor(
         stats (dict, optional): a dictionary containing the :obj:`loc` and :obj:`scale` for the `ObservationNorm` transform
         norm_obs_only (bool, optional): If `True` and `VecNorm` is used, the reward won't be normalized online.
             Default is `False`.
-        use_env_creator (bool, optional): wheter the `EnvCreator` class should be used. By using `EnvCreator`,
+        use_env_creator (bool, optional): whether the `EnvCreator` class should be used. By using `EnvCreator`,
             one can make sure that running statistics will be put in shared memory and accessible for all workers
             when using a `VecNorm` transform. Default is `True`.
         custom_env_maker (callable, optional): if your env maker is not part
@@ -644,7 +644,7 @@ def make_transformed_env(**kwargs) -> TransformedEnv:
         elif custom_env_maker is None and custom_env is not None:
             env = custom_env
         else:
-            raise RuntimeError("cannot provive both custom_env and custom_env_maker")
+            raise RuntimeError("cannot provide both custom_env and custom_env_maker")
 
         if cfg.env.noops and custom_env is None:
             # this is a bit hacky: if custom_env is not None, it is probably a ParallelEnv
@@ -699,7 +699,7 @@ def initialize_observation_norm_transforms(
 
     Args:
         proof_environment (EnvBase instance, optional): if provided, this env will
-            be used ot execute the rollouts. If not, it will be created using
+            be used to execute the rollouts. If not, it will be created using
             the cfg object.
         num_iter (int): Number of iterations used for initializing the :obj:`ObservationNorms`
         key (str, optional): if provided, the stats of this key will be gathered.