[SciPy-dev] design of a physical quantities package: seeking comments

[Corran Webster]

Hi all,

I'm new to the scipy-dev list, but we're just wrapping up a project  
here at Enthought where I've used the current Enthought units  
infrastructure.  If I have time today I'll add my comments based on  
our experience here with using physical quantities in a real-world  
project.

My main comment here is the following:

On Aug 3, 2008, at 2:46 AM, Anne Archibald wrote:

> 2008/8/2 Darren Dale <dsdale24 at gmail.com>:
>
>> On Saturday 02 August 2008 4:23:43 pm Anne Archibald wrote:
>>> 2008/8/2 Darren Dale <dsdale24 at gmail.com>:
>>> What about user-defined functions? It's worth having some kind of
>>> decorator that enforces that a particular function acts on something
>>> with no units, and maybe enforces particular units.
>>
>> Could you give an example? I don't follow.
>
> Well, suppose I have a function that, like "exp", only accepts
> unitless quantities. Suppose in fact it's already written. It would be
> nice to have a decorator so all I have to write is
>
> @unitless
> def myfunc(x):
> ...
>
> Similarly, if I want to implement the Planck black-body function, it
> would be nice to be able to write
>
> @units(K,Hz)
> def B(T,nu):
> ...

For an example of this sort of idea already implemented (although not  
with this particular interface), have a look at the @has_units  
decorator in enthought.numerical_modelling.units.  It is designed to  
parse docstrings to extract unit information for the input and output  
variables.

Other than that, I'd observe that variables with unit information were  
a significant source of bugs and additional effort in our development  
effort.  To be fair, they probably helped identify a lot of bugs too.   
But we had to write a fair bit of code whose sole purpose was to add  
or remove units from variables.

For example, we have a solver in the application which uses  
scipy.optimize.fsolve.  To make it work correctly, we had to take our  
variables with user-supplied units, remove the units, but remember  
them in context, and then inside the function we were trying to solve  
for we would have to re-apply the units before calling the code which  
performed the computations (which then usually did its own unit  
conversions before actually computing anything meaningful).

We also hit some of the limitations of a simple physical quantities  
system: this particular application involved fluid dynamics, and in  
particular power-law fluids, where one of the key physical quantities,  
consistency, has units of Pa*s**n where n is the shear index, another  
key physical quantity.  In particular, n was variable in the  
situations we were dealing with, and so we had to special-case the  
consistency variables and ensure that they were always in a particular  
set of units everywhere in our code.

I haven't had time yet to sit back and look hard at how the unit  
libraries could have been improved to make our experience smoother.   
As I mentioned earlier, if I have time today I'll respond to this  
thread in detail and try and make some concrete constructive  
suggestions.

Best Regards,
Corran