[SciPy-dev] integration of Unum in scipy

Travis N. Vaught travis at enthought.com
Tue Feb 21 10:58:27 CST 2006

DE MENTEN Sebastien wrote:
>> Somewhat. Personally, I have Issues with all existing unit packages
> mostly
>> summarized by how they handle (or don't handle) temperatures. We've
>> discussed
>> this before. Start here:
>>   http://www.scipy.net/pipermail/scipy-user/2005-March/004263.html
> I share your view expressed in
> http://www.scipy.net/pipermail/scipy-user/2005-March/004266.html
> (absolute temperature translation is not a unit conversion). However,
> after looking at the implementation in enthought.units, I have two
> questions:
>  1) Is the dependence on the rest of enthough framework (e.g. traits)
> easily replaced/removed?
>  2) Am I right in saying that the system is tight to the SI? Are the 7
> physical unit dimensions hardcoded? Is it possible to add exotic system
> of units (e.g. currencies)?
> Unum provides an engine that enables the creation of units (m,kg,...) as
> well as unum objects (3 m/s, [3,6,7] kg,...). In this regard, it looks
> more generic than enthought.units.
> Finally, do you have feedback on people using this module in enthought? 
> Best,
> Seb

The ties to traits, etc., _should_ all be optional.  The base package 
(units.unit) is usable in a very stand-alone way.  It is correct that 
the system is "tight to the SI" -- you'd have to derive a class or 
modify the core functionality to extend for things like currency.

For "quantities" we typically use the quantity module, which allows for 
a composite object that has 'data' and 'units' where data can be a 
float, or an array (or other sequence) of floats.  This was to enable 
the performance gains of dealing with math on arrays of floats rather 
than an array of unit objects.

There is much more in the overall package which handles both Unit 
Systems and, orthogonally, some style information (default ranges, 
plotting styles, etc.) that is completely optional.

As far as feedback goes, the core units package is very trouble-free for 
us--we haven't had to do much to the code in a while for it to perform 
for us.  On the other hand, the total package sees quite a bit of 
tweaking and cajoling to get it integrated into applications in the way 
we want with the performance we want.



Travis N. Vaught
Enthought, Inc.

More information about the Scipy-dev mailing list