[boost] Re: Physical Quantity- boostified

From: Andy Little (andy_at_[hidden])
Date: 2003-11-06 16:50:01

"Deane Yang" <deane_yang_at_[hidden]> wrote in message
news:bodnkn$v1r$1_at_sea.gmane.org...
> Andy Little wrote:
> > Hi  ,
> >
> >     In  the previous debate about Physical Quantities,
> >     An interesting question that came up was
> >  What should the resulting units of  a calculation between two different
> > types of units be?
> >
> > (solution proposed)
>
> I confess that I am a little mystified to why this is even needed,
> and it leads me to wonder if how I envision using such a
> library is different from everyone else. I apologize if this has
> already been discussed, but could someone explain exactly why
> something like:
>
> inferred_type add_units(units_type first, other_units_type second)
>
> is useful?

operators      ..... !    :-)
BTW One thing is usefulness. The other is simply that this is now a
challenge for me to solve.
... because its there and all that

>
> My immediate reaction, on the contrary, is that this leads to
> the compiler quietly allowing changing of units without any
> warning to the programmer, which can have undesirable consequences
> (such as loss of precision).

My solution is based Solely on the combination of units that preserves
precision.
the finest grained units.
 (
    Bear in mind that when power_of_unit < 0 finest grained and coarsest
grained invert.
I have "solved" (for me :-)  ) addition but multiplication and division set
other challenges - powers of a unit may vary between operands.
hence to find best involves resolving the actual scaling unit * power at
compile time.
It is more complex but  achievable (with some limitations due to fp) .. I
hope ... multiplication and division are my current task
)

*Note: this is slightly different to my previous example and demonstrates a
conversion where the unitiated would protest !

#include <iostream>
#include "physical_quantities.hpp"
#include "physical_quantities_demo_util.hpp"
using namespace physical_quantities;
int main()
{

    pq_velocity<int>::m_per_minute V1(1);        // metres per minute
    pq_velocity<int>::mm_per_s       V2(1);        // millimetres per second

    std::cout << V1 - V2 <<'\n';
    std::cout << V2 - V1 <<'\n';

    return 0;
}
////////////////////////////
 output:
   940 mm.minutes-1                // millimetres per ninute (ie different
units to either V1 or V2 :-) )
  -940 mm.minutes-1                // not  intuitive but No loss in
precision
//////////////////////////////////
In this case I conjecture that conversion to either the type of V1 or V2
might lose precision, but I may be wrong in that

I see this conversion as being the physical_quantity analogy to inbuilt
conversions to the "best" type:

int x;
float y;
float z = x * y;
                ^^^ implicit conversion no warning given

of course you can force it to do what you want with both inbuilt and my pqs

 float zz  =  x  *  static_cast<int>( y);

pq_velocity<float>::mm_per_s      x(1);
pq_velocity<float>::m_per_minute  y(1);

pq_velocity<float>::mm_per_s    z  =  x
    +  static_cast<pq_velocity<float>::mm_per_s>( y );
//or
pq_velocity<float>::mm_per_s    zz  =  x
    +  pq_velocity<float>::mm_per_s( y );
// or
pq_velocity<float>::mm_per_s    zzz  =  x +  y ;
//ideally compiler warning given         ^

[ a lot more snipped- will answer when have digested ]
Andy Little