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

From: Steven Watanabe (steven_at_[hidden])
Date: 2007-02-15 23:12:55

AMDG

Noah Roberts <roberts.noah <at> gmail.com> writes:

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

My question was: Why should x and y store the
unit, when that information is just going to
be thrown away and replaced by user_selected_unit?
Is this converted value going to be used for
any other purpose than to output it or convert
it back to the base system for more calculation?

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

A few clarifications are in order. I have
assumed that the only use for a dynamic
unit system is to read and write quantities
in units to be determined at runtime. If
This assumption is wrong then I will accept
the utility of runtime units.  Even then,
I don't really like to add them to Units.
If it is possible to cleanly implement
it as a separate library on top of Units
then that would be my first choice.

The dimension code can be used wholesale.
A runtime quantity can be constructed
from a static quantity.  Adding two
runtime quantities yields a static
quantity.  A static quantity should
be constructible fro a runtime quantity too.
That is the only hitch I see.

There is one ugliness in your proposal.

quantity<pressure> p1(psi);
quantity<pressure> p2(pascals);
p1 = whatever;
p2 = p1;

Now, what should the unit of p2 be?

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

I agree with you there.  However, static conversions
are common enough to warrent consideration and can be
cleanly integrated into the rest of the library.

In Christ,
Steven Watanabe