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