Re: [boost] [Review] Quantitative Units library review begins today, March 26

From: Matthias Schabel (boost_at_[hidden])
Date: 2007-03-28 18:42:43

Michael,

Michael,

Thanks for your positive review. I'm glad that the library is working  
for you in a practical setting - that's always a concern for us  
academics divorced from the real world ;^)

> specialization is simply the reciprocal of the first.  Steven posted a
> solution to this in a separate thread just now and I hope that it will
> get included in the final version.

This should not be a problem; I'm accumulating a list of changes to  
be made as they come in.

> Example 16 looks strangely familiar!  Glad to see it was interesting
> enough to make the examples.

Your example was actually the impetus driving the decision to  
implement heterogeneous units, a project that I know Steven spent a  
significant amount of time and effort to get right...

> sure if this unit makes sense in the nautical namespace.  One might
> ask "Why not boost::aerial?"  The only reason I bring this up is
> because they are used for marine and aerial navigation.  There may be

I tend to try to name things so they sound right if you read them;  
even though they are used in aerial navigation, as far as I  
understand they are still called nautical miles, so to my eye  
nautical::miles reads right.

> other such examples, but I think all of the non_si_units.hpp units
> could reside in a boost::non_SI namespace with little confusion to the
> user.  These would be all non-SI, but accepted, units (see
> http://en.wikipedia.org/wiki/Non-SI_units_accepted_for_use_with_SI).

This is probably one of the darker corners left in the library; I'm  
hoping that reviewer input will help to shape the final form of the  
non-SI portion of the library. Steven has some ideas for dealing with  
the irregularities of US/Imperial units in a relatively clean and  
elegant way. However, putting all of these into the same namespace is  
problematic because there are, for example, differing definitions of  
units having the same name (mile, in particular) so us_customary,  
us_survey, and nautical miles are all slightly discrepant.

> I also noticed that the unit knots was not defined in
> non_si_units.hpp.  Is this an oversight?  Why are some accepted non-SI
> units defined and others not?

I just have very limited personal experience with and use for these  
traditional units, so I didn't think to add it. I'm certainly happy  
to put knots in. I don't believe they were listed in the NIST  
documents I was referencing. Because there are so many irregular  
units out there, I'm reluctant to promise to support everything under  
the sun in the library, but the decision of where to stop is a bit  
arbitrary. I just used the NIST document as my yardstick (sorry...)

> Is there an exhaustive list in the docs mentioning all units and  
> their systems?

There is not yet, but should be.

> Yes, certainly.  I would, however, like to hear Matthias' and Steven's
> thoughts on how easy it would be to add a run-time layer on top of
> their existing work.

A runtime component would be essentially a parallel library that  
replicated the existing dimensional analysis functionality in runtime  
code. I've mentioned previously that it would be relatively easy to  
specialize to get a syntax like quantity<arbitrary,Y> that looks much  
the same as the existing syntax. It probably wouldn't be hard to  
implement runtime algorithms; I am still extremely skeptical that  
there are many users out there who would be willing to pay the  
computational cost and memory overhead of doing all of the  
dimensional analysis at runtime. At a bare minimum, I would like to  
see some "real" use cases where it isn't possible to get reasonable  
behavior with the existing library. As you mention, the current  
implementation works fine with GUIs as long as you're willing to pick  
an internal representation for the units used at compile time. There  
would also need to be compile-time -> runtime conversions, input  
parsing, etc... which would involve varying degrees of effort - the  
latter probably will be hardest...

Matthias