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

From: Noah Roberts (roberts.noah_at_[hidden])
Date: 2007-02-13 16:43:41

Steven Watanabe wrote:
> AMDG
> 
> Noah Roberts <roberts.noah <at> gmail.com> writes:
> 
>> Frankly put, I don't have a use for a library that does static unit 
>> conversions.  We work in one system of units and convert into/out of 
>> those units when required to arbitrary units the user specifies and 
>> there are of course only a few dimensions we do this in.  I have a hard 
>> time seeing a situation in which this isn't the way you would want to go 
>> about it.
>>
> 
> As has been stated before, this library is primarily about
> type safety.  The conversions are a secondary concern.
>>From what you are saying I think that you have not seriously
> considered what the implementation should look like.  There
> are two basic possibilities
> 
> 1) Store everything in some standard unit system and also
>    store the conversion factor to the requested system.
> 
> 2) Store the value in the requested unit system and remember
>    the conversion factor to the standard system.
> 
> How should addition and subtraction be defined? You cannot
> require that the operands have the same unit.  Otherwise
> harmless looking code such as
>     1.0 * joules + (2.0 * kilograms * pow<2>(2.5 * meters / second)) / 2;
> might not work.  Converting the second to match
> the first will work but loses precision.  If you
> use 2. to avoid the precision loss brought about
> by the conversions involved in 1., by the time
> you are finished you will end up losing more
> precision than if you had simply converted to SI
> to begin with.

"Converting the second to match the first" doesn't make sense to me.  I 
guess you might be talking about operands of '+'?  Yeah, not necessary.

The answer is pretty simple.  All arithmetic operators work in the base 
system.  The result is converted on assignment if necessary.

> 
> Both of these require storing twice as much information
> as the current implementation.

There is one condition in which that is necessary.  That is if you are 
using a value that is entered by the user and the calculation loop keeps 
requesting it from whatever object it is provided by.  Then, in order 
that the conversion isn't repeatedly done you would want to store two 
values...the user entered value and the converted value.  The reason you 
wouldn't just store the converted value is double creep...the number 
might change on the user.  I imagine that a developer who needs to can 
work with this so that it does not happen...so that the calculation loop 
is not asking for the same conversion on the same value repeatedly.

Any other time it is sufficient that you keep only the user entered 
value and the unit (ie the conversion factor) to translate it into the 
base system...OR...the converted value in the base system without a 
conversion factor.

   The inefficiency is
> probably more than a simple factor of two because the
> size increase will most likely force the compiler to continually
> load and store instead of keeping the values in a register.
> 
> Any more complex approach will add even more overhead.
> For example, storing a sorted dimension list necessiates
> a call to merge for every single multiplication or division.

Don't know why any of that would be necessary.