Re: [boost] Units: brief review

From: Matthias Schabel (boost_at_[hidden])
Date: 2007-03-26 18:14:45

Phil,

Thanks for taking a look.

> The units of the heat transfer coefficient are W C^-1 m^-2.  As far  
> as I was able to see, I was not able to write anything like
>
> typedef quantity<power/temperature/area> heat_transfer_coefficient_t;

If your compiler supports native typeof, you can just write this:

typedef typeof(watts/kelvin/pow<2>(meter))   
heat_transfer_coefficient_unit_type;

typedef quantity<heat_transfer_coefficient_unit_type>    
heat_transfer_coefficient_t;

> Rather, it was necessary for me to reduce W C^-1 m^-2 to basic  
> dimensions manually.  This is not easy for me.  I have to remember  
> phyics that I

If and when auto type deduction becomes a reality in C++, this will  
all become much simpler. For the meantime, you can either use the  
typeof trick above or you can compute the unit in a small test  
program like this :

std::cout << watts/kelvin/pow<2>(meter) << std::endl;

to get the units :

kg s^(-3) K^(-1)

> so I concluded that the dimensions of power are mass length time^-3  
> and hence of heat transfer coefficient are mass time^-3  
> temperature^-1 length^-1, and wrote this:

Congrats - you got it right. Here's a complete program that does what  
you want (to this point, anyway) :

#include <iostream>

#include <boost/units/io.hpp>
#include <boost/units/unit.hpp>
#include <boost/units/quantity.hpp>
#include <boost/units/systems/si.hpp>

using namespace boost::units;
using namespace boost::units::SI;

typedef quantity<power>         power_t;
typedef quantity<area>          area_t;
typedef quantity<temperature>   temp_diff_t;

typedef typeof(watts/kelvin/pow<2>(meter))   
heat_transfer_coefficient_unit_type;

typedef quantity<heat_transfer_coefficient_unit_type>    
heat_transfer_coefficient_t;

int main()
{
     const heat_transfer_coefficient_t  
watts_per_square_meter_per_kelvin = 1.0*watts/square_meter/kelvin;

     std::cout << heat_transfer_coefficient_unit_type() << std::endl
               << watts_per_square_meter_per_kelvin << std::endl
               << std::endl;

     return 0;
}

outputting

kg s^(-3) K^(-1)
1 kg s^(-3) K^(-1)

> typedef composite_dimension<mass_tag, 
> 1,time_tag,-3,temperature_tag,-1,length_tag,-1>
>   heat_transfer_coefficient_t;

This is the correct dimension. You need to associate it with a unit  
system to get a unit :

typedef unit<heat_transfer_coefficient_t,SI::system>	si_htc_unit_t;

> Defining the unit was easier:
>
> const heat_transfer_coefficient_t watts_per_square_meter_per_celcis
>   = watts / square_meter / kelvin;
>
> But this fails to compile, with this error:

<snip>

You tried to assign a unit to a quantity; quantities can be expressed  
as value_type*unit, so what you want to do is

const quantity<si_htc_unit_t>	watts_per_square_meter_per_celcius =  
7.4*watts/square_meter/kelvin;

> For this library to be useful for me, it needs to be quick to learn  
> and easy to apply.  Working only with the included units it does  
> look like it would work reasonably well, but in the situation I  
> have described above it was quickly obvious that it was taking more  
> effort to apply it to my program than the benefit that would result.

All I can say is that dimensional analysis and units is more  
complicated than it seems it ought to be... Compiler support for  
typeof and auto or emulation using Boost.Typeof goes a long way to  
simplify things. I am also happy to add more commonly used units to  
the library as they crop up...

> 1. What is the effect on compile time?  I used #if to switch  
> between units and plain floats.

Since the work is done with metaprogramming on lists, the overhead  
depends on how numerous and how complex the units used are. Steven's  
work on the implementation side has made, I believe, the compile  
times quite manageable for the examples we present, even those that  
use many different units.

> 2. Is there any increase in object file size?  I know there  
> shouldn't be, but it would be interesting to know for sure.

Steven seems to have addressed this.

> 3. Are the error messages comprehensible?  The one show above is  
> not great, but it could have been worse; there are some Boost  
> libraries which I find unusable because of the volumne and  
> inpenetrability of the error messages that result from a simple  
> typo (though the compiler must share the blame for this).

We've done what we could to make error messages occur near the point  
of the actual error and be as reasonable as possible, but, as with  
most template metaprogramming code, errors can't really be described  
as terse. If you're doing a lot of programming with units, they begin  
to become easier to decipher...

> - "io" is a misnomer since it only does output, as far as I can see.

Good point. We'll have to think of a better name, I guess...

> - I tend to refer to temperature differences in Celcius, rather  
> than Kelvin.  There is an obvious issue when dealing with absolute  
> temperatures though.

Take a look at unit_example_20 - this deals specifically with the  
absolute/relative temperature conversion issue...

> - Please don't call the units used in the U.S. "English" units.   
> Here in England, we use the S.I. system for everything except pints  
> of beer and miles on roadsigns.  The units that we did use here  
> until about 50 years ago were not the same as the ones that the  
> Americans use.

In boost/units/systems/other/non_si_units.hpp I have included  
conversion factors for Imperial units (the ones used in the recent  
past in England), US Customary units, US Survey units, nautical  
units, some non-SI metric units, etc... English units generally refer  
to heterogeneous and obsolete units, while Imperial and US Customary  
are the main non-SI systems still in some use... See here, also :

http://en.wikipedia.org/wiki/English_unit

> I hope this helps.  I will not express an opinion about whether the  
> library should be included; I leave that to people who have made  
> more progress with it.

Thank you for your input and comments. If you do find some more time  
to work with it, I would certainly appreciate any additional input  
you might have.

Matthias