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