# [SciPy-user] Units in SciPy

Wed Mar 30 17:16:00 CST 2005

```Duncan Child wrote:
> Hi all,
>
> We have been using the units package written by Michael Aivaziz which is
> available here:
>
> http://www.cacr.caltech.edu/projects/pyre/
> http://www.cacr.caltech.edu/projects/pyre/epydoc/public/pyre.units-module.html
>
> One potential issue is that a units package has to guess whether the
> user wants to convert a temperature gradient or a temperature:
>
> 1Celsius = 274.15Kelvin (absolute)
>
> For a proprietary project Enthought reworked Michael's package to assume
> temperatures are absolute. This is maybe less surprising to a regular
> user but was tantamount to forking Michael's project. It also leaves the
> inherent ambiguity unresolved. If we put Mike's work into scipy we would
> probably want to use it unchanged.
>
> So my questions are:
>
> 1) any interest out there in us putting a units package into scipy?

Yes.  Note that Scientific (Konrad's) also has units support.  I just mention
it for reference, I can't say anything in terms of comparisons.

> 3) does anyone have input or suggestions regarding the temperature issue?

Putting my physicist hat on, I'd strongly argue for simply saying that
temperatures are temperatures, period.  If you need to convert temperature
_differences_ (gradients), you should explicitly say so.  It's OK for a
package to provide utility functions to do this conveniently, if it's a
frequent need.  But the concept of temperature should be unchanged:

T_celsius = T_kelvin - 274.15

This formula implicitly encapsulates the fact that delta_t_celsius ==
delta_t_kelvin, but it's the only formula with basic physical meaning.  The
relative size of the unit steps is a simple consequence of this formula.  And
I think that good scientific libraries should encode, when possible, the more
basic concepts, while providing whichever higher-level utility functions are
deemed necessary.

Just my \$.02

Best,

f

```