I have been making extensive use of some C++ classes I wrote to do compile time unit analysis in IMP. I find them very useful and wouldn t want to have to write code without them and as a result thought I would ask if others are interested. They enable things like - automatically converting between different length measures (say angstroms and nanometers) so you don't have to worry which number is which - check that unit types match, so can can't assign an energy value to a force or daltons to kilograms - convert between SI units and the energy units used in IMP etc. You use them by writing things like Nanometer side(10); CubicAngstrom volume= side*side*side; Nanosecond time_step(10); simulation_parameters.set_maximum_time_step(time_step); // it otherwise would want femtoseconds
As a said, I quite like using them and would like to make them generally available. There are a couple of holdups: - since it is a compile time library, it doesn't really translate to python, so we would need to continue to provide separate units and unit free interfaces for things (for example SimulationParameters has set_maximum_time_step and set_maximum_time_step_in_femtosecond, the latter just takes a double - Boost, has added its own units library (as of 1.36). It is based on the same principles as mine (they both grew out of a Boost.MPL example) but there are various differences so converting to the boost one would take a bit of work and we would need to provide some of our own code on top of the boost library.
My thought had been to wait until IMP required a new enough boost and switch to that, but it is taking a while. Are people interested? The code is pretty stable, but could use a bit of documentation and cleanup if others are to use it.
Daniel Russel wrote: > My thought had been to wait until IMP required a new enough boost and > switch to that, but it is taking a while. Are people interested? The > code is pretty stable, but could use a bit of documentation and > cleanup if others are to use it.
I don't really see the application of general units in most cases, and would prefer we stick with conventions on what units to use (e.g angstroms for distances). My main concerns are numerical inaccuracies creeping in with an inappropriate choice of units (e.g. passing meters into something that stores internally as angstroms - it would be better if the user knew that was the representation was) and how any output values are displayed - are you suggesting a unit conversion on output as well as input? That said, it's nice to have explicit units to reduce confusion (e.g. MMTK has similar IIRC). I'm not so keen on two functions for everything though, since that's twice as much code to test. It seems like we should able to handle this in Python with suitable proxy classes and typemaps anyway.
As for Boost, 1.36 is really new and I'd prefer not to use a version that hasn't made its way into the mainstream stable distributions like CentOS yet. We don't want to force everybody to use Fedora.
Ben
> I don't really see the application of general units in most cases, and > would prefer we stick with conventions on what units to use (e.g > angstroms for distances). For me, the main temptation to put it in the public interface comes from things like diffusion constants where there are a few possible choices and no one will remember the IMP convention for it. I'm not sure how many such cases are likely to come up.
> My main concerns are numerical inaccuracies > creeping in with an inappropriate choice of units (e.g. passing meters > into something that stores internally as angstroms - it would be better > if the user knew that was the representation was) Why is this an issue? As long as you don't run out of exponent bits (which meters to angstroms, for example, would not), such conversions don't introduce any numerical error at all. Right?
The other nice thing about how units are in IMP is that they allow you to avoid overflow of exponential bits in intermediate results (I was having problems with that when converting between SI and MD units since you have to convert to per mole in there). But that is something that IMP can benefit from without exposing units to users.
> and how any output > values are displayed - are you suggesting a unit conversion on output as > well as input? One of the other nice things is that you can have consistent pretty printed output on measurements (not that the current output is very pretty, but it could be fixed :-). But the application user side of things isn't really my domain and I don't know enough to talk about conventions there.
If you mean output of functions, I quite like being not having to think what the units on, say get_current_time_step() are.
> I'm not so keen on two functions > for everything though, since that's twice as much code to test. Agreed.
> It seems > like we should able to handle this in Python with suitable proxy classes > and typemaps anyway. I'm sure it can be done. But I think doing it in a useful manner would be a large amount of work and I'm also sure I don't want to write it :-) Which is why I think we would be stuck with dual interfaces for the forseeable future if we make units ubiquitous and haven't pushed it.
> As for Boost, 1.36 is really new and I'd prefer not to use a version > that hasn't made its way into the mainstream stable distributions like > CentOS yet. We don't want to force everybody to use Fedora. Yes, we should support the most recent CentOS at least.
participants (2)
-
Ben Webb -
Daniel Russel