Boost logo

Boost :

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

"Deane Yang" <deane_yang_at_[hidden]> wrote in message
> 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
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;
   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
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 );
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

Boost list run by bdawes at, gregod at, cpdaniel at, john at