Unit systems - gxyd/sympy GitHub Wiki

This page aims to discuss possible improvements that can be made on unit systems (sympy.physics.unitsystems) in SymPy as well as open questions. Usage information can be found in the documentation.

Improvements

The most important steps are to define missing unit systems, to improve quantity calculus and to parse string argulent (such as "10 m").

Quantity calculus

Currently computations can only be done with numbers and definite units. The module should be extended to allow computations with other kinds of objects and also unknown variables.The best approach would be to define a quantity as a pair (X, D) where

  • X is a magnitude and can be a number, a symbol, an array, etc.
  • D is the dimension whose powers can be numbers or symbols.

Computations can be done without using a system. A given quantity (i.e. a pair) can be printed as soon as we choose a system, whose base units can be use as rulers. From this point of view there is no conversion: we have some objects and we pick a representation for it, we do not change between several representations (the only conversion that could happen is when we define the pair from a quantity).

This can be implemented without broking anything in the current module and this is the most interesting way to go:

  • attach dimensions to symbols in usual equations ;
  • dimensional analysis will be straightforward ;
  • equations for quantities will be simplified ;
  • define only one dimension object for an array (instead of having them in all entries) ;
  • and many more.

New unit systems

Several systems have to be defined:

  • SI
  • Planck system
  • computer science system
  • astronomical system (with ua, earth mass, solar radius, etc.)
  • imperial system

Add systems also for k_b = 1 (Boltzmann's constant).

Dimensional analysis

A lot of things can be done with dimensional analysis.

  • Parse equations to check dimensions (there is already a function for this, but its very rough).
  • Implement Buckingham Π theorem: find all adimensional quantities with n quantities and N base units.

New objects

Several kinds of new objects can be implemented:

  • Units with offset (like °C).
  • Logarithmic units (dB, pH, bytes, etc.) : one has to take care to allow log in different basis (cf [deBoer79]).
  • Quantities with uncertainties.

Moreover the Constant class is strictly identical to Unit class for the moment, but it could be useful to improve it to reflect the fact that it is a little more than just units.

Printing quantities and units

Nice printing is important to the end users.

  • Default printing should be done in the base units of the given system.
  • Option: if there exists non-base units of the same dimension, use the one that gives the closest factor to 1 (ex.: 1.7e6 eV will be written 1.7 MeV).
  • Option: the user can asks the result to contain some units, then complete with other units (the minimum number) to match dimensions (ex.: 1 Pa will be written 1 N m^-2 if the user asked to have N).
  • Define sympy printing for the different objects (use the package siunitx for LaTeX).

Checks

Operations with units can be tricky so several check could be added (or helpers defined for the user) to test if everything is well-defined:

  • When a system display a unit, be sure that the object is compatible with the system.
  • Verify that function arg are dimensionless (there is care to take with angles, cf the references below).
  • Dimension powers can not be integers since intermediate computations may involve square roots. Then we could have a function to test if the end dimension is physical by having all powers to be integer (up to some uncertainty due to numerical rouding).

Misc

  • Parse Quantity argument like "10 m".
  • Define time systems (like hour/minutes/seconds), calendars.
  • Add angles be added to MKS(A) [LevyLeblond98].
  • Improve access to units and dimensions in systems:
    • find by name or symbol ;
    • allow string argument ;
    • retrieve several units using tuples/lists ;
    • access to dimensions and units like attributes (e.g. mks.length).

Open questions

The module can already be used in daily life, but it will need some polishing in order to be fully convenient to use. In this section I suggest several points that could be improved.

Operations with units and numbers

This is the big question: currently operations with units return either a unit or an instance Add/Mul/Pow. The main problem is for add/sub: we can get units with negative scale, which has no sense with regard to the way we defined them. The solution could be that every operation implying a unit return a quantity. For example 10*m return the quantity Quantity(10, m); similarly Unit(length, 10) - Unit(length, 20) returns Quantity(-10, m).

Conversions and priting

A lot of work is needed to tie better units and unit systems. For example if one wants to define a quantity with Quantity("10 m"), we have somehow to say what is the current system. One could define a global variable SYSTEM which says in which system one wants to work, and then add some function in units to take this into account (but some people don't like global variables).

Historical discussions

For some historical discussions you can take a look at:

References