On 19 September 2016 at 07:23, Oliver Lemke <oliver.le...@uni-hamburg.de> wrote:
> Lukas and me had a discussion on how to handle the functions that require
> pint. We would like to turn the units/pint functionality into a subpackage of
> physics. The idea is that all functions directly under physics are operating
> on SI units without any pint dependency. Functions that do support units
> should go into the units subpackage. For functions in physics, small wrapper
> functions can be added in the units subpackage that use pint to convert the
> inputs to SI units and then call the plain function from the physics package.
> Is that ok with you?
That makes a lot of sense. Specifically, I think when we say "SI
units" we mean "base SI units", which is good for consistency even
though it's sometimes unusual (for example, g/mol is more common than
kg/mol). How do you want to handle functions/classes outside the
physics/ subpackage? My HIRS reading routine by defaults uses base SI
frequency radiance [W / sr / m² / Hz], but this is very unusual and
confused two colleagues already, so I added an option to return what
everybody else uses, [W / sr / m² / cm^-1]; I use pint to convert
between the two (a third alternative would be [W / sr / m], likely to
confuse equally if not more).
typhon.mi mailing list