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

From: Noah Roberts (roberts.noah_at_[hidden])
Date: 2007-02-16 11:23:29

Steven Watanabe wrote:
> 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?

Well, presumably it is used elsewhere.

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

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

The other use is to write code like so:

quantity f() { static quantity const C = 9.43 * psi; ... equation 
written with psi constant ... }

  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.

This is why I think the concepts in the library need to be better 
documented.  What makes a quantity a quantity, a unit a unit, etc...

It's one thing to say, "Hey, just override XYZ struct deep inside the 
implementation and it will work," and providing real documentation so a 
person doesn't have to know the implementation upside and down to do it.
> 
> 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?

pascals.  The rule is conversion on assignment.  This does cause some 
need to be careful with such things as std containers that work through 
assignment.