What is Pint ?#
Pint is a Python package to define, operate and manipulate physical quantities: the product of a numerical value and a unit of measurement. It allows arithmetic operations between them and conversions from and to different units.
It is distributed with a comprehensive list of physical units, prefixes and constants. Due to its modular design, you can extend (or even rewrite!) the complete list without changing the source code. It supports a lot of numpy mathematical operations without monkey patching or wrapping numpy.
It has a complete test coverage. It runs in Python 3.9+ with no other dependencies. It is licensed under a BSD 3-clause style license.
It is extremely easy and natural to use:
>>> import pint
>>> ureg = pint.UnitRegistry()
>>> 3 * ureg.meter + 4 * ureg.cm
<Quantity(3.04, 'meter')>
and you can make good use of numpy if you want:
>>> import numpy as np
>>> [3, 4] * ureg.meter + [4, 3] * ureg.cm
<Quantity([ 3.04 4.03], 'meter')>
>>> np.sum(_)
<Quantity(7.07, 'meter')>
See the Tutorial for more help getting started.
Design principles#
Although there are already a few very good Python packages to handle physical quantities, no one was really fitting my needs. Like most developers, I programmed Pint to scratch my own itches.
Unit parsing: prefixed and pluralized forms of units are recognized without explicitly defining them. In other words: as the prefix kilo and the unit meter are defined, Pint understands kilometers. This results in a much shorter and maintainable unit definition list as compared to other packages.
Standalone unit definitions: units definitions are loaded from a text file which is simple and easy to edit. Adding and changing units and their definitions does not involve changing the code.
Advanced string formatting: a quantity can be formatted into string using PEP 3101 syntax. Extended conversion flags are given to provide symbolic, LaTeX and pretty formatting. Unit name translation is available if Babel is installed.
Free to choose the numerical type: You can use any numerical type
(fraction, float, decimal, numpy.ndarray, etc). NumPy is not
required, but is supported.
Awesome NumPy integration: When you choose to use a NumPy ndarray, its methods and
ufuncs are supported including automatic conversion of units. For example
numpy.arccos(q) will require a dimensionless q and the units of the output
quantity will be radian.
Uncertainties integration: transparently handles calculations with quantities with uncertainties (like 3.14±0.01) meter via the uncertainties package.
Handle temperature: conversion between units with different reference points, like positions on a map or absolute temperature scales.
Dependency free: it depends only on Python and its standard library. It interacts with other packages like numpy and uncertainties if they are installed
Pandas integration: The pint-pandas package makes it possible to use Pint with Pandas. Operations on DataFrames and between columns are units aware, providing even more convenience for users of Pandas DataFrames. For full details, see the pint-pandas Jupyter notebook.
When you choose to use a NumPy ndarray, its methods and
ufuncs are supported including automatic conversion of units. For example
numpy.arccos(q) will require a dimensionless q and the units
of the output quantity will be radian.
One last thing#
The MCO MIB has determined that the root cause for the loss of the MCO spacecraft was the failure to use metric units in the coding of a ground software file, “Small Forces,” used in trajectory models. Specifically, thruster performance data in English units instead of metric units was used in the software application code titled SM_FORCES (small forces). The output from the SM_FORCES application code as required by a MSOP Project Software Interface Specification (SIS) was to be in metric units of Newtonseconds (N-s). Instead, the data was reported in English units of pound-seconds (lbf-s). The Angular Momentum Desaturation (AMD) file contained the output data from the SM_FORCES software. The SIS, which was not followed, defines both the format and units of the AMD file generated by ground-based computers. Subsequent processing of the data from AMD file by the navigation software algorithm therefore, underestimated the effect on the spacecraft trajectory by a factor of 4.45, which is the required conversion factor from force in pounds to Newtons. An erroneous trajectory was computed using this incorrect data.
Mars Climate Orbiter Mishap Investigation Phase I Report PDF
License#
Copyright (c) 2012 by Hernan E. Grecco and contributors. See AUTHORS
for more details.
Some rights reserved.
Redistribution and use in source and binary forms of the software as well
as documentation, with or without modification, are permitted provided
that the following conditions are met:
* Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
* Redistributions in binary form must reproduce the above
copyright notice, this list of conditions and the following
disclaimer in the documentation and/or other materials provided
with the distribution.
* The names of the contributors may not be used to endorse or
promote products derived from this software without specific
prior written permission.
THIS SOFTWARE AND DOCUMENTATION IS PROVIDED BY THE COPYRIGHT HOLDERS AND
CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT
NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER
OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE AND DOCUMENTATION, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
DAMAGE.