Re: [boost] formal review request : mcs::units

From: Matthias Schabel (boost_at_[hidden])
Date: 2007-02-06 18:04:15

> - I had to modify <boost/units/system/si/base.hpp> to include
> <boost/units/io.hpp>, otherwise the compiler claimed syntax errors for
> all of the specializations of the unit_info class.

Good point; I'll fix this.

> - Compile times even for a relatively small sample were rather large,
> but this is understandable.

Yeah, compile time is a bear. On the other hand, I haven't gone  
through the
MPL code with a fine-toothed comb yet, so it might be possible to  
make some
improvements there. In any case, for most projects, you would just  
throw the
quantities you want into a precompiled header file, so it should  
really only be
a one-time cost...

> - unit_info specializations for the CGS system typedef'd base_type as
> SI::system, not CGS::system.  Is this a bug?  This typedef is also
> omitted in the docs, so I'm not even sure it's necessary.

The quantity conversion code has seen more change than anything else  
since
v0.5.6 - base_type is no longer necessary as I no longer assume that  
conversions
between two unit systems have to be mediated by a base system.  
Instead, as
you can see in <boost/units/systems/si/convert_si_to_cgs.hpp>, you  
simply
provide a template specialization for the base_unit_converter class  
for each
fundamental unit. This marginally increases the typing involved in  
implementing
unit system conversions, but significantly increases the  
flexibility... I have removed
the unnecessary base_type declarations for the next version.

> So far my sample program makes two new units, nautical miles and feet.
> Nautical miles resides in SIext::system, feet resides in
> imperial::system.  It then defines a radar struct that stores a range
> in nautical miles, and a ceiling in feet, as well as a location in UTM
> coordinates as meters.  There is one function in_range that takes in a
> UTM coordinate and says whether or not it's in range of the given
> radar system.

Cool - this sounds like a much more interesting application than most  
of the
largely SI stuff that I use it for...

> One issue that using feet brought up was how to correctly specialize
> the unit_info struct for the unit name string when the name changes in
> plural form.  Could you provide a plural() function that does nothing
> but forward to name() if it's not over-ridden?  e.g.
>
> template <>
> struct unit_info<imperial::system, length_tag>
> {
>   typedef imperial::system base_type;
>   static string name() { return "foot"; }
>   static string plural() { return "feet"; }
>   static string symbol() { return "ft"; }
> };

I guess it would not be a problem in principle to do this. Since the  
current IO
doesn't use the full name anyway, you could just add plural() and  
have it work.
The only downside I can see to adding this to the library (assuming I  
can figure
out how to get an ostream manipulator to enable the choice of full  
unit names
or abbreviations) is that operator<< would have to compare value()  
against Y(1).
Another potential issue is this:

What should you call 1 lb. ft.? I'd say one foot pound. How about 2  
lb. ft? I'd say
two foot pounds. But it could equally reasonably be called two pound  
feet - it's
just a convention. With more involved composite units, these issues  
become
progressively messier, which is one of the reasons why I've tried as  
much as
possible to avoid the morass of IO...

> minor nit.  Just in implementing this small program I was warned by
> the compiler of comparing feet to meters multiple times (comparing
> altitudes).  I will try to clean up the code and send it to you if you
> are interested.  I would also be interested if I used your library's
> facilities correctly.

I'd be very interested to see what you've done with it and to get  
your overall
impression on the documentation and ease of use.

Thanks,

Matthias

----------------------------------------------------------------
Matthias Schabel, Ph.D.
Assistant Professor, Department of Radiology
Utah Center for Advanced Imaging Research
729 Arapeen Drive
Salt Lake City, UT  84108
801-587-9413 (work)
801-585-3592 (fax)
801-706-5760 (cell)
801-484-0811 (home)
matthias dot schabel at hsc dot utah dot edu
----------------------------------------------------------------