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.ht...
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