Boost logo

Boost :

From: Daryle Walker (darylew_at_[hidden])
Date: 2003-11-13 04:23:35


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 it.
>> 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.

> 1 metre is equal to 1000mm
> is equal to etc...
> They are all different ways of saying the same thing. Its an everyday thing, a
> 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"). In fact, the table "=" is a writing
convention and has no algorithmic meaning (unlike C++'s "=" or "==").

> However
> The different units have evolved because ,when dealing with big lengths it
> is easier to use a bigger unit.

That sounds kind-of arbitrary.

> 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.

> That goes for Floating Point too. If you only need big lengths you want them
> at the scale of the unit.
[TRUNCATE]

That last sentence doesn't make sense. (Which "unit" do you mean?)

The real problem is that computer numbers don't have infinite precision
_nor_ infinite digit space.

* Keep the bigger unit -> value from smaller unit could shrink below
precision and/or (worse) below lowest exponent
* Keep the smaller unit -> value from bigger unit could grow above highest
exponent or maximum number of stored digits (from zero padding).

Daryle


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk