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

From: Noah Roberts (roberts.noah_at_[hidden])
Date: 2007-02-15 17:50:59

Steven Watanabe wrote:
> AMDG
> 
> Noah Roberts <roberts.noah <at> gmail.com> writes:
> 
>> Steven Watanabe wrote:
>>> std::cout << (x + y) << std::endl;
>> Nothing good would probably come of it the way I see things; but since 
>> mcs does magic unit label stuff it could just output that.  Without, 
>> allowing for the user to override certain behavior this could be more 
>> well behaved:
>>
>> std::cout << ((x + y) * unit) << std::endl;
>>
>> You're probably not too worried about the moderate overhead of the extra 
>> work there when I/O is going to be bottlenecking anyway.
>>
>> Except in debugging, the developer is going to have a pretty strong idea 
>> of what units need labels and create them.  Other units and dimensions 
>> are of no consequence.
> 
> Agreed.  If you have to specify the unit at
> this point, what is the purpose of tracking
> it dynamically at all, though?

I hadn't really considered this use case.  For most purposes I think x + 
y will be assigned to something and stored and most, if not all, 
calculations would be done in functions working in fundamental units.

However, it is a legitimate use.  Why track units at all at this point? 
  Well theoretically you could have the unit selected at some earlier 
point and stored in a variable so that you might do:

std::cout << ((x + y) * user_selected_unit) << std::endl;

The alternative to requiring this notation would be to pick one or the 
other...probably the left operand.  In my opinion that isn't verbose 
enough and is rather arbitrary.

My intended use is more akin to:

quantity<pressure> dp(psi);
dp = x - y;
std::cout << dp << std::endl;

with lots of stuff going on in between.
> 
>> Yes, there is an overhead to the unit but it is localized to the places 
>> where conversion is necessary.  The library user does have to use some 
>> care, and I haven't thought of a way to allow them to use this stuff 
>> willy nilly in something needing extreem performance, but I don't think 
>> that is too much to expect.
>>
> 
> I'm afraid that I am still unconvinced that runtime
> units are useful.  Here are the basic scenarios
> and solutions.  Perhaps I forgot something?
> 
> 1) The dimensions are known at compile time but
>    the unit system depends on user input.
> 
>   a) Losing a few bits of precision doesn't hurt.
> 
>       Do all internal calculations in SI (e.g.) and
>       track the units to print separately.  The
>       printed units need never appear anywhere
>       outside of the IO code.  It is cleaner to
>       keep them there rather than having them possibly
>       propogate out, only to be translated immediately
>       into SI anyway.

There are a few things I am concerned about.  First, a user entered 
value is a value that has a set unit.  It makes sense for these to be 
together.  Since these should be kept together it makes sense for them 
to be also held with a static dimension to coincide with their future 
use in calculations.  That being the case it makes sense for this to bi 
similar and compatible with a static dimension quantity.  Second, I 
don't like the idea of having two separate unit systems...one for the 
static quantity and one for the dynamic.  Optimally a psi unit would be 
used in both of the following:

quantity<pressure> dp(psi);

and inside a pressure calculation function:

stat_quantity<pressure> calc_whatever()
{
   static stat_quantity<pressure> const C = 5.43 * psi;
   ...
}

The second is because often times equations are written with a given set 
of units and contain constants in units possibly not in the base. 
Allows you to keep the code in line with the domain it models.

It would be especially nice if that same psi could be used in static 
conversions but that's a heavy feature for minor benefit.  I also don't 
believe static conversions to new base systems are going to be that 
common in most applications.