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