
Boost : 
From: Andy Little (andy_at_[hidden])
Date: 20031106 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.minutes1 // millimetres per ninute (ie different
units to either V1 or V2 :) )
940 mm.minutes1 // 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk