/usr/share/doc/python-pint-doc/html/_sources/index.txt is in python-pint-doc 0.6-1ubuntu1.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 | :orphan:
Pint: a Python units library
============================
.. image:: _static/logo-full.jpg
:alt: Pint: **physical quantities**
:class: floatingflask
Pint is 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 2.6+ and 3.2+ with no other dependency. It licensed under BSD.
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 programed 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.
**Free to choose the numerical type**: You can use any numerical type (`fraction`, `float`, `decimal`, `numpy.ndarray`, etc). NumPy is not required but supported.
**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.
**Handle temperature**: conversion between units with different reference points, like positions on a map or absolute temperature scales.
**Small codebase**: easy to maintain codebase with a flat hierarchy.
**Dependency free**: it depends only on Python and its standard library.
**Python 2 and 3**: a single codebase that runs unchanged in Python 2.7+ and Python 3.0+.
User Guide
----------
.. toctree::
:maxdepth: 1
getting
tutorial
numpy
nonmult
wrapping
serialization
pitheorem
contexts
measurement
defining
More information
----------------
.. toctree::
:maxdepth: 1
contributing
faq
One last thing
--------------
.. epigraph::
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 <ftp://ftp.hq.nasa.gov/pub/pao/reports/1999/MCO_report.pdf>`_
|