[MNT] Fix typos (#1988)

#### What does this implement/fix? Explain your changes.

Correct misspellings with https://github.com/crate-ci/typos

#### What should a reviewer concentrate their feedback on?

Please help me find false positives.

Author: szepeviktor

CHANGELOG.md

@@ -45,12 +45,12 @@ Release focusing on:
 * [BUG] Fix issue with `EncodeNormalizer(method='standard', center=False)` for scale value by @fnhirwa in https://github.com/sktime/pytorch-forecasting/pull/1902
 * [BUG] fixed memory leak in `TimeSeriesDataset` by using `@cached_property` and clean-up of index construction by @Vishnu-Rangiah in https://github.com/sktime/pytorch-forecasting/pull/1905
 * [BUG] Fix issue with `plot_prediction_actual_by_variable`  unsupported operand type(s) for *: 'numpy.ndarray' and 'Tensor' by @fnhirwa in https://github.com/sktime/pytorch-forecasting/pull/1903
-* [BUG] Correcly set lagged variables to known when lag >= horizon by @hubkrieb in https://github.com/sktime/pytorch-forecasting/pull/1910
+* [BUG] Correctly set lagged variables to known when lag >= horizon by @hubkrieb in https://github.com/sktime/pytorch-forecasting/pull/1910
 * [BUG] Updated base_model.py to account for importing error by @Himanshu-Verma-ds in https://github.com/sktime/pytorch-forecasting/pull/1488
 * [BUG][DOC] Fix documentation: pass loss argument to BaseModel in custom models tutorial example by @PranavBhatP in https://github.com/sktime/pytorch-forecasting/pull/1931
 * [BUG] fix broken version inspection if package distribution has `None` name by @lohraspco in https://github.com/sktime/pytorch-forecasting/pull/1926
 * [BUG] fix sporadic `tkinter` failures in CI by @fkiraly in https://github.com/sktime/pytorch-forecasting/pull/1937
-* [BUG] Device inconstency in `MQF2DistributionLoss` raising: RuntimeError: Expected all tensors to be on the same device by @fnhirwa in https://github.com/sktime/pytorch-forecasting/pull/1916
+* [BUG] Device inconsistency in `MQF2DistributionLoss` raising: RuntimeError: Expected all tensors to be on the same device by @fnhirwa in https://github.com/sktime/pytorch-forecasting/pull/1916
 * [BUG] fixed memory leak in BaseModel by detach some tensor by @zju-ys in https://github.com/sktime/pytorch-forecasting/pull/1924
 * [BUG] Fix `TimeSeriesDataSet` wrong inferred `tensor` `dtype` when `time_idx` is included in features by @cngmid in https://github.com/sktime/pytorch-forecasting/pull/1950
 * [BUG] standardize output format of xLSTMTime estimator for point predictions by @sanskarmodi8 in https://github.com/sktime/pytorch-forecasting/pull/1978
@@ -381,7 +381,7 @@ Maintenance update widening compatibility ranges and consolidating dependencies:
 
 ### Changed
 
-- Dropping Python 3.6 suppport, adding 3.10 support (#479)
+- Dropping Python 3.6 support, adding 3.10 support (#479)
 - Refactored dataloader sampling - moved samplers to pytorch_forecasting.data.samplers module (#479)
 - Changed transformation format for Encoders to dict from tuple (#949)
 
@@ -408,7 +408,7 @@ Maintenance update widening compatibility ranges and consolidating dependencies:
 - Allow using [torchmetrics](https://torchmetrics.readthedocs.io/) as loss metrics (#776)
 - Enable fitting `EncoderNormalizer()` with limited data history using `max_length` argument (#782)
 - More flexible `MultiEmbedding()` with convenience `output_size` and `input_size` properties (#829)
-- Fix concatentation of attention (#902)
+- Fix concatenation of attention (#902)
 
 ### Fixed
 
@@ -430,7 +430,7 @@ Maintenance update widening compatibility ranges and consolidating dependencies:
 ### Fixed
 
 - Fix inattention mutation to `x_cont` (#732).
-- Compatability with pytorch-lightning 1.5 (#758)
+- Compatibility with pytorch-lightning 1.5 (#758)
 
 ### Contributors
 
@@ -517,7 +517,7 @@ Maintenance update widening compatibility ranges and consolidating dependencies:
 
 ### Added
 
-- Adding a filter functionality to the timeseries datasset (#329)
+- Adding a filter functionality to the timeseries dataset (#329)
 - Add simple models such as LSTM, GRU and a MLP on the decoder (#380)
 - Allow usage of any torch optimizer such as SGD (#380)
 
@@ -586,7 +586,7 @@ Maintenance update widening compatibility ranges and consolidating dependencies:
 ### Added
 
 - Adding support for multiple targets in the TimeSeriesDataSet (#199) and amended tutorials.
-- Temporal fusion transformer and DeepAR with support for multiple tagets (#199)
+- Temporal fusion transformer and DeepAR with support for multiple targets (#199)
 - Check for non-finite values in TimeSeriesDataSet and better validate scaler argument (#220)
 - LSTM and GRU implementations that can handle zero-length sequences (#235)
 - Helpers for implementing auto-regressive models (#236)

README.md

@@ -75,7 +75,7 @@ To implement new models or other custom components, see the [How to implement ne
 
 # Usage example
 
-Networks can be trained with the [PyTorch Lighning Trainer](https://pytorch-lightning.readthedocs.io/en/latest/common/trainer.html) on [pandas Dataframes](https://pandas.pydata.org/pandas-docs/stable/user_guide/dsintro.html#dataframe) which are first converted to a [TimeSeriesDataSet](https://pytorch-forecasting.readthedocs.io/en/latest/data.html).
+Networks can be trained with the [PyTorch Lightning Trainer](https://pytorch-lightning.readthedocs.io/en/latest/common/trainer.html) on [pandas Dataframes](https://pandas.pydata.org/pandas-docs/stable/user_guide/dsintro.html#dataframe) which are first converted to a [TimeSeriesDataSet](https://pytorch-forecasting.readthedocs.io/en/latest/data.html).
 
 ```python
 # imports for training
@@ -122,7 +122,7 @@ batch_size = 128
 train_dataloader = training.to_dataloader(train=True, batch_size=batch_size, num_workers=2)
 val_dataloader = validation.to_dataloader(train=False, batch_size=batch_size, num_workers=2)
 
-# create PyTorch Lighning Trainer with early stopping
+# create PyTorch Lightning Trainer with early stopping
 early_stop_callback = EarlyStopping(monitor="val_loss", min_delta=1e-4, patience=1, verbose=False, mode="min")
 lr_logger = LearningRateMonitor()
 trainer = pl.Trainer(

docs/source/faq.rst

@@ -27,7 +27,7 @@ Creating datasets
   200 for the decoder length. Consider that longer lengths increase the time it takes
   for your model to train.
 
-  The ratio of decoder and encoder length depends on the used alogrithm.
+  The ratio of decoder and encoder length depends on the used algorithm.
   Look at :ref:`documentation <models>` to get clues.
 
 * **It takes very long to create the dataset. Why is that?**
@@ -61,7 +61,7 @@ Training models
 
 * **Why does the learning rate finder not finish?**
 
-  First, ensure that the trainer does not have the keword ``fast_dev_run=True`` and
+  First, ensure that the trainer does not have the keyword ``fast_dev_run=True`` and
   ``limit_train_batches=...`` set. Second, use a target normalizer in your training dataset.
   Third, increase the ``early_stop_threshold`` argument
   of the ``lr_find`` method to a large number.

docs/source/index.rst

@@ -52,7 +52,7 @@ To use the MQF2 loss (multivariate quantile loss), also execute
 
    pip install pytorch-forecasting[mqf2]
 
-Vist :ref:`Getting started <getting-started>` to learn more about the package and detailled installation instruction.
+Visit :ref:`Getting started <getting-started>` to learn more about the package and detailed installation instruction.
 The :ref:`Tutorials <tutorials>` section provides guidance on how to use models and implement new ones.
 
 .. toctree::

docs/source/installation.rst

@@ -81,7 +81,7 @@ Contributing to ``pytorch-forecasting``
 Contributions to PyTorch Forecasting are very welcome! You do not have to be an expert in deep learning
 to contribute. If you find a bug - fix it! If you miss a feature - propose it!
 
-To obtain an editible version ``pytorch-forecasting`` for development or contributions,
+To obtain an editable version ``pytorch-forecasting`` for development or contributions,
 you will need to set up:
 
 * a local clone of the ``pytorch-forecasting`` repository.
@@ -128,7 +128,7 @@ Creating a fork and cloning the repository
       > upstream  https://github.com/sktime/pytorch-forecasting.git (fetch)
       > upstream  https://github.com/sktime/pytorch-forecasting.git (push)
 
-Setting up an editible virtual environment
+Setting up an editable virtual environment
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 1. Set up a new virtual environment. Our instructions will go through the commands to set up a ``conda`` environment which is recommended for ``pytorch-forecasting`` development.
@@ -183,13 +183,13 @@ Technical Design Principles
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 When writing code for your new feature, it is recommended to follow these
-technical design principles to ensure compatability between the feature and the library.
+technical design principles to ensure compatibility between the feature and the library.
 
 * Backward compatible API if possible to prevent breaking code.
 * Powerful abstractions to enable quick experimentation. At the same time, the abstractions should
   allow the user to still take full control.
 * Intuitive default values that do not need changing in most cases.
-* Focus on forecasting time-related data - specificially timeseries regression and classificiation.
+* Focus on forecasting time-related data - specifically timeseries regression and classification.
   Contributions not directly related to this topic might not be merged. We want to keep the library as
   crisp as possible.
 * Install ``pre-commit`` and have it run on every commit that you make on your feature branches.

docs/source/metrics.rst

@@ -30,7 +30,7 @@ predictions add up. For example:
 
 Here we add to MAE an additional loss. This additional loss is the MAE calculated on the mean predictions
 and actuals. We can also use other metrics such as SMAPE to ensure aggregated results are unbiased in that metric.
-One important point to keep in mind is that this metric is calculated accross samples, i.e. it will vary depending
+One important point to keep in mind is that this metric is calculated across samples, i.e. it will vary depending
 on the batch size. In particular, errors tend to average out with increased batch sizes.
 
 

docs/source/models.rst

@@ -9,7 +9,7 @@ Model parameters very much depend on the dataset for which they are destined.
 
 PyTorch Forecasting provides a ``.from_dataset()`` method for each model that
 takes a :py:class:`~data.timeseries.TimeSeriesDataSet` and additional parameters
-that cannot directy derived from the dataset such as, e.g. ``learning_rate`` or ``hidden_size``.
+that cannot directly derived from the dataset such as, e.g. ``learning_rate`` or ``hidden_size``.
 
 To tune models, `optuna <https://optuna.readthedocs.io/>`_ can be used. For example, tuning of the
 :py:class:`~models.temporal_fusion_transformer.TemporalFusionTransformer`
@@ -47,7 +47,7 @@ Availability of covariates
 .. _model-covariates:
 
 If you have covariates, that is variables in addition to the target variable itself that hold information
-about the target, then your case will benefit from a model that can accomodate covariates. A model that
+about the target, then your case will benefit from a model that can accommodate covariates. A model that
 cannot use covariates is :py:class:`~pytorch_forecasting.models.nbeats.NBeats`.
 
 Length of timeseries
@@ -58,7 +58,7 @@ most models are created and tested on very long timeseries while in practice sho
 timeseries are often encountered. A model that can leverage covariates well such as the
 :py:class:`~pytorch_forecasting.models.temporal_fusion_transformer.TemporalFusionTransformer`
 will typically perform better than other models on short timeseries. It is a significant step
-from short timeseries to making cold-start predictions soley based on static covariates, i.e.
+from short timeseries to making cold-start predictions solely based on static covariates, i.e.
 making predictions without observed history. For example,
 this is only supported by the
 :py:class:`~pytorch_forecasting.models.temporal_fusion_transformer.TemporalFusionTransformer`
@@ -72,7 +72,7 @@ If your time series are related to each other (e.g. all sales of products of the
 a model that can learn relations between the timeseries can improve accuracy.
 Not that only :ref:`models that can process covariates <model-covariates>` can
 learn relationships between different timeseries.
-If the timeseries denote different entities or exhibit very similar patterns accross the board,
+If the timeseries denote different entities or exhibit very similar patterns across the board,
 a model such as :py:class:`~pytorch_forecasting.models.nbeats.NBeats` will not work as well.
 
 If you have only one or very few timeseries,
@@ -86,7 +86,7 @@ Not every can do regression, classification or handle multiple targets. Some are
 geared towards a single task. For example, :py:class:`~pytorch_forecasting.models.nbeats.NBeats`
 can only be used for regression on a single target without covariates while the
 :py:class:`~pytorch_forecasting.models.temporal_fusion_transformer.TemporalFusionTransformer` supports
-multiple targets and even hetrogeneous targets where some are continuous variables and others categorical,
+multiple targets and even heterogeneous targets where some are continuous variables and others categorical,
 i.e. regression and classification at the same time. :py:class:`~pytorch_forecasting.models.deepar.DeepAR`
 can handle multiple targets but only works for regression tasks.
 
@@ -97,18 +97,18 @@ Supporting uncertainty
 ~~~~~~~~~~~~~~~~~~~~~~~
 
 Not all models support uncertainty estimation. Those that do, might do so in different fashions.
-Non-parameteric models provide forecasts that are not bound to a given distribution
+Non-parametric models provide forecasts that are not bound to a given distribution
 while parametric models assume that the data follows a specific distribution.
 
 The parametric models will be a better choice if you
 know how your data (and potentially error) is distributed. However, if you are missing this information or
 cannot make an educated guess that matches reality rather well, the model's uncertainty estimates will
-be adversely impacted. In this case, a non-parameteric model will do much better.
+be adversely impacted. In this case, a non-parametric model will do much better.
 
-:py:class:`~pytorch_forecasting.models.deepar.DeepAR` is an example for a parameteric model while
+:py:class:`~pytorch_forecasting.models.deepar.DeepAR` is an example for a parametric model while
 the :py:class:`~pytorch_forecasting.models.temporal_fusion_transformer.TemporalFusionTransformer`
 can output quantile forecasts that can fit any distribution.
-Models based on normalizing flows marry the two worlds by providing a non-parameteric estimate
+Models based on normalizing flows marry the two worlds by providing a non-parametric estimate
 of a full probability distribution. PyTorch Forecasting currently does not provide
 support for these but
 `Pyro, a package for probabilistic programming <https://pyro.ai/examples/normalizing_flows_i.html>`_ does
@@ -120,7 +120,7 @@ Computational requirements
 Some models have simpler architectures and less parameters than others which can
 lead to significantly different training times. However, this not a general rule as demonstrated
 by Zhuohan et al. in `Train Large, Then Compress: Rethinking Model Size for Efficient Training and Inference of Transformers
-<https://arxiv.org/abs/2002.11794>`_. Because the data for a sample for timeseries models is often far samller than it
+<https://arxiv.org/abs/2002.11794>`_. Because the data for a sample for timeseries models is often far smaller than it
 is for computer vision or language tasks, GPUs are often underused and increasing the width of models can be an effective way
 to fully use a GPU. This can increase the speed of training while also improving accuracy.
 The other path to pushing utilization of a GPU up is increasing the batch size.