Typo fixes

kerrm · Nov 11, 2022 · 75ba018 · 75ba018
1 parent e9c41b6
commit 75ba018
Show file tree

Hide file tree

Showing 10 changed files with 21 additions and 14 deletions.
diff --git a/CHANGELOG.md b/CHANGELOG.md
@@ -48,7 +48,7 @@ and this project, at least loosely, adheres to [Semantic Versioning](https://sem
 ### Changed
 - `model.phase()` now defaults to `abs_phase=True` when TZR* params are in the model
 - TOAs no longer need to be grouped by observatory
-- removed explicit download of IERS and leapsecond data (handled now by astropy)
+- removed explicit download of IERS and leap second data (handled now by astropy)
 - The default version of TT(BIPM) uses BIPM2021
 - ClockFile no longer uses metaclass magic or many subclasses, and have friendly names for use in messages
 - `model.setup()` now gets called automatically after removing a parameter as part of `remove_param`
@@ -193,7 +193,7 @@ and this project, at least loosely, adheres to [Semantic Versioning](https://sem
 ## [0.8] - 2020-12-21
 ### Fixed
 - Fixed an indentation bug in Wideband TOA fitting.
-- The CombinedResidual class has API change on the get_data_error(), child residueal class in save as dictionary.
+- The CombinedResidual class has API change on the get_data_error(), child residual class in save as dictionary.
 ### Removed
 - Removed Python 2.7 support from travis and tox testing suites and from requirements files
 - Removed "landscape" code checker since that package is no longer supported by its author
@@ -288,7 +288,7 @@ and this project, at least loosely, adheres to [Semantic Versioning](https://sem
 - Add function to compute epoch averaged residuals based on ECORR
 - Added model comparison pretty printer
 - Added functions to change PEPOCH, DMEPOCH, and binary epoch
-- Aded dmxparse function
+- Added dmxparse function
 - Added code to ensure that IERS B table is up to date
 - Added fitter.print_summary()
 ### Changed

diff --git a/CONTRIBUTING.rst b/CONTRIBUTING.rst
@@ -134,7 +134,7 @@ Before you submit a pull request, check that it meets these guidelines:
 1. Try to write clear :ref:`pythonic` code, follow our :ref:`CodingStyle`, and think
    about how others might use your new code.
 2. The pull request should include tests that cover both the expected
-   behaviour and sensible error reporting when given bad input.
+   behavior and sensible error reporting when given bad input.
 3. If the pull request adds or changes functionality, the docs should
    be updated. Put your new functionality into a function with a
    docstring. Check the HTML documentation produced by ``make docs``

diff --git a/HISTORY.rst b/HISTORY.rst
@@ -1,4 +1,11 @@
 History
 =======
 
-TEMPO was originally written in the 1980s, aiming for microsecond-level accuracy. TEMPO2 was written more recently, with an attention to nanosecond-level effects. Both are still in current use. But TEMPO is in FORTRAN, TEMPO2 is in C++, and neither is easy to extend for use in tasks different from plain pulsar timing. Most of TEMPO2 is also a direct conversion of TEMPO, so many bugs from TEMPO were carried over to TEMPO2. PINT was created to be, as far as possible, an independent reimplementation based on existing libraries - notably astropy - and to be a flexible toolkit for working with pulsar timing models and data.
+TEMPO was originally written in the 1980s, aiming for microsecond-level accuracy. 
+TEMPO2 was written more recently, with an attention to nanosecond-level effects. 
+Both are still in current use. But TEMPO is in FORTRAN, TEMPO2 is in C++, and neither 
+is easy to extend for use in tasks different from plain pulsar timing. Most of TEMPO2 
+is also a direct conversion of TEMPO, so many bugs from TEMPO were carried over to 
+TEMPO2. PINT was created to be, as far as possible, an independent re-implementation 
+based on existing libraries - notably astropy - and to be a flexible toolkit for 
+working with pulsar timing models and data.
diff --git a/README.rst b/README.rst
@@ -96,7 +96,7 @@ it, ensuring that all dependencies needed to run PINT are available::
     $ cd PINT
     $ pip install .
 
-Complete installation instructions are availble here_.
+Complete installation instructions are available here_.
 
 .. _here: https://nanograv-pint.readthedocs.io/en/latest/installation.html
 

diff --git a/docs/coding-style.rst b/docs/coding-style.rst
@@ -26,7 +26,7 @@ PINT coding style
    - Every public function or class should have a docstring. It
      should be in the correct format (numpy guidelines_).
    - Do not abbreviate public names (for example, use "Residuals"
-     not "resids"). If *aboslutely* necessary, make certain that there
+     not "resids"). If *absolutely* necessary, make certain that there
      is One True Abbreviation and that it is used everywhere.
    - Raise an exception if the code cannot continue and produce
      correct results.
@@ -44,7 +44,7 @@ PINT coding style
      available the ``pulsar_mjd`` time format.
    - PINT should work with python 2.7, 3.5, 3.6, 3.7, and later. There
      is no need to maintain compatibility with older versions, so use
-     approprate modern constructs like sets, iterators, and the string
+     appropriate modern constructs like sets, iterators, and the string
      ``.format()`` method.
    - Use six_ to manage python 2/3 compatibility problems.
 

diff --git a/docs/command-line.rst b/docs/command-line.rst
@@ -25,7 +25,7 @@ pintk
 pintbary
 --------
 
-``pintbary`` does quick barycentering calculations, convering an
+``pintbary`` does quick barycentering calculations, converting an
 MJD(UTC) on the command line to TDB with barycentric delays applied. The
 position used for barycentering can be read from a par file or from the
 command line

diff --git a/docs/development-setup.rst b/docs/development-setup.rst
@@ -30,7 +30,7 @@ able to do the following:
    - Jump to the definition of a function, class, or method with a keypress.
    - Obey ``.editorconfig`` settings.
 
-A little Googling should reveal how to get all this working in your favourite
+A little Googling should reveal how to get all this working in your favorite
 editor, but if you have some helpful links for a particular editor feel free to
 add them to the documentation right here.
 

diff --git a/docs/editing-documentation.rst b/docs/editing-documentation.rst
@@ -87,7 +87,7 @@ You may also want to run, from time to time::
 
 This will try to make sure that all the external links in the documentation
 still work, though of course they can't verify that the page that comes up is
-still the indended one and not `something else`_.
+still the intended one and not `something else`_.
 
 .. _Sphinx: http://www.sphinx-doc.org/en/master/
 .. _reStructuredText: http://docutils.sourceforge.net/rst.html

diff --git a/docs/explanation.rst b/docs/explanation.rst
@@ -147,7 +147,7 @@ in, and what kind of time you're asking for::
 
 The conventional time scale for working with pulsars, and the one PINT
 uses, is Barycentric Dynamical Time (TDB). You should be aware that there
-is another time scale, not yet supported in PINT, called Baycentric
+is another time scale, not yet supported in PINT, called Barycentric
 Coordinate Time (TCB), and that because of different handling of
 relativistic corrections, it does not advance at the same rate as TDB
 (there is also a many-second offset). TEMPO2 uses TCB by default, so
@@ -646,7 +646,7 @@ TEMPO and TEMPO2 can check whether the predicted improvement of chi-squared, ass
 
 This algorithm is the Gauss-Newton_algorithm_ for solving nonlinear
 least-squares problems, and even in one-complex-dimensional cases can exhibit
-convergence behaviour that is literally chaotic_. For TEMPO/TEMPO2 and PINT, the
+convergence behavior that is literally chaotic_. For TEMPO/TEMPO2 and PINT, the
 problem is that the model is never actually evaluated at the updated starting
 point before committing to it; it can be invalid (ECC > 1) or the step can be
 large enough that the derivative does not match the function and thus the

diff --git a/docs/installation.rst b/docs/installation.rst
@@ -126,7 +126,7 @@ The virtualenv mechanism uses environment variables to create an isolated
 python environment into which you can install and upgrade packages without
 affecting or being affected by anything in any other environment. Unfortunately
 it is possible to defeat this by setting the ``PYTHONPATH`` environment
-vairable. Double unfortunately, setting the ``PYTHONPATH`` environment used to
+variable. Double unfortunately, setting the ``PYTHONPATH`` environment used to
 be the Right Way to use python things that weren't part of your operating
 system. So many of us have ``PYTHONPATH`` set in our shells. You can check this::