From: Andy Little (andy_at_[hidden])
Date: 2003-11-16 15:19:12
"Daryle Walker" <darylew_at_[hidden]> wrote in message
> On 11/13/03 11:30 AM, "Andy Little" <andy_at_[hidden]>
> > "Daryle Walker" <darylew_at_[hidden]> wrote in message
> > news:BBD8B7C7.27CC%darylew_at_hotmail.com...
> >> On 11/6/03 8:33 PM, "Andy Little" <andy_at_[hidden]>
> >>> "Deane Yang" <deane_yang_at_[hidden]> wrote in message
> >>> news:boekps$3rl$1_at_sea.gmane.org...
> >>>> I want to know why it is useful to be able to add two quantities with
> >>>> different units and have the operator+ do the unit conversion inside
> >>>> I'm sure there's an obvious answer that will make me feel very dumb.
> >>> There is a very obvious answer:
> >>> from , random book close at hand:
> >>> Ross Garrett "The symmettry of sailing ,1987 Appendix B"
> >>> Length m km inch foot nautical mile
> >>> 1 metre = 1 10-3 39.37 3.281 5.4x10-4
> >>> 1 kilometre = ......
> >>> etc.
> >>>> >>
> >> No it doesn't.
> > Oh ...yes ... it ... Does. :-)
> It depends on how you see the "=" token. See below.
> >>> 1 metre is equal to 1000mm
> >>> is equal to etc...
> >>> They are all different ways of saying the same thing. Its an everyday
> >>> a commonly understood concept. If you have =, you soon need +, * ...
> >> Yikes! The "=" in the table has nothing to do with the one for C++
> >> equivalent to" vs. "assignment").
> > hmm... Did I say "The Symmetry of Sailing " is written in C++ ?
> >> In fact, the table "=" is a writing
> >> convention and has no algorithmic meaning (unlike C++'s "=" or "==").
> > ????...
> I was worried that you saw the "=" in the table and decided to blindly map
> it to an assignment operator (because it has the same symbol). From your
> usage examples, I see that you aren't using it like assignment, you're
> it as an implicit conversion constructor (that's what a "=" in a
> statement is).
ho... hum...hmm ...worry on... I have also mapped it to operator= , and I
see nothing wrong with that :-)
ie The type does both initialisation by, and assignment from, another pq
( both pqs MUST have equivalent Powers of Dimension, ie you can only
assign_to/init_by a length a length, a force a force etc,
BUT units that pq is expressed in can be different ):
// default ctor
std:: cout << "init by default ctor, v1 <-- "<< v1 <<'\n';
// explicit value ctor, note1,note2
std:: cout << "init by value ctor, v2 <-- "<< v2 <<'\n';
// "implicit conversion ctor " aka Daryle Walker
pq_velocity<>::miles_per_hour v3 = v2;
std::cout << "init by impl conv ctor, v3 <-- " << v3 <<'\n';
// ..... ok so far AND ... assignment is allowed too ....
v1 = v3;
std:: cout << "v1 after assignment by v3, v1 <-- "<< v1 <<'\n';
init by default ctor, v1 <-- 0 m.minutes-1
init by value ctor, v2 <-- 16.6667 mm.s-1
init by impl conv ctor, v3 <-- 0.0372823 miles.hours-1
v1 after assignment by v3, v1 <-- 1 m.minutes-1
note1: value gives easy mental conv to m_per_minute
note2: implicit value ctor is obviously not allowed,ie
pq_velocity<>::mm_per_s v2 = 1000/60.0f; // Error! Destroys dimensional
OK To explain whats going on here
As an example of a physical quantity take the keyboard I am typing at.
It has a certain 'length' :
Measuring with a ruler in inches gives 17.75 in.
Measuring with a ruler in millimetres gives 450 mm.
I hope you agree that the length of the keyboard has not changed.
Measuring in millimetres provides an expression for the length
Measuring in inches gives an expression for the length.
the units are different, the values are different but ....
....the two expressions represent the Same length.
The two expressions are equivalent in terms of "How long the keyboard
Each expression provides all the information required to create another
object the same length as the keyboard.
The two expressions are trivially different("in","mm", and 'raw value':-)),
but both describe the same entity completely.
The (ideal) physical_quantity type models this concept exactly.
The entity enters the system expressed in one unit and can be extracted in
that or any other unit.
the underlying m_value may changes, the units may change but the underlying
pq entity remains intact.
There appears to be a lack of type safety, but there isnt, the type safety
is provided by the rules of dimensional analysis.
Furthermore in reality units must be attached to a pq else it has no
"How fast are you going?"
" I am travelling it 3.5" // meaningless / incomprehensible
"I am travelling at Mach 3.5" // nice...
The physical_quantity type always keeps track of whats units its in for this
but (ideally) doesnt favour one units policy over another, that is up to
The concept behind the physical_quantity type is simple.
The = sign says it all.
BTW trudging on with docs , tests, and fernicketty gcc
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk