[SciPy-user] Units in SciPy

Fernando Perez Fernando.Perez at colorado.edu
Wed Mar 30 18:16:00 EST 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 = 1Kelvin    (gradient)
> 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




More information about the SciPy-User mailing list