From: Andy Little (andy_at_[hidden])
Date: 2003-11-13 11:30:25
"Daryle Walker" <darylew_at_[hidden]> wrote in message
> On 11/6/03 8:33 PM, "Andy Little" <andy_at_[hidden]> wrote:
> > "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 of
> >> 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.
> > The = sign says it all.
> No it doesn't.
Oh ...yes ... it ... Does. :-)
> > 1 metre is equal to 1000mm
> > is equal to etc...
> > They are all different ways of saying the same thing. Its an everyday
> > commonly understood concept. If you have =, you soon need +, * ... etc
> Yikes! The "=" in the table has nothing to do with the one for C++ ("is
> 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 "==").
An example algorithm using my physical_quantities class:
using namespace physical_quantities;
pq_velocity<float>::m_per_s v1(1); // metres per second
pq_velocity<float>::miles_per_s v2 = v1; //v1 in miles per
std::cout << v1 << " is equivalent to " << v2
<< " is " << std::boolalpha << ( v2 == v1 ) <<'\n';
1 m.s-1 is equivalent to 0.000621371 miles.s-1 is true
If you dont like the sailing example see
NIST special publication 811,
guide for the Use of the International System of Units,
P8, table 6 etc
or any cookery book :-)
> > However
> > The different units have evolved because ,when dealing with big lengths
> > is easier to use a bigger unit.
> That sounds kind-of arbitrary.
The arbitrariness or otherwise of evolution is slightly off topic....
> > There are just less zeros to stick on there. Its easier to deal with.
> No, it's not. The zeros just get tacked on the other end.
???? Oh you mean if you change units :-)
I GHz = 1000000 kHz
= 1000000000 Hz
= 1000000000000000000000000000000000 yHz.
= 0.000000000000001 YHz
(note ... I could have missed a couple of 0's here and there... apologies)
> > That goes for Floating Point too. If you only need big lengths you want
> > at the scale of the unit.
> That last sentence doesn't make sense. (Which "unit" do you mean?)
see here for an overview... :
general note: I hope to put an implementation on the boost files
section sooner or later. I feel that I should
provide some level of robustness, adequate explanation justification etc,
which all takes time.
> The real problem is that computer numbers don't have infinite precision
> _nor_ infinite digit space.
hmm...I usually muddle through somehow, without infinite precision. :-)
Physics is based on measurement.
Measurement is inaccurate.
Floating point numbers generally do more than a good enough job.
I conjecture that most problems are of the "division by zero" type. ie lazy
programming (yes guilty :- ) )
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk