From: "trans.  (T. Onoma)" <transami@...>
Date: 2004-10-31T04:38:33+09:00
Subject: Re: Rounding error ... [remainder of huge subject line truncated]

On Saturday 30 October 2004 02:44 pm, Lloyd Zusman wrote:
| The "better world" you are talking about already exists.  I will explain
| that point below.
|
| People who understand the concepts of fixed-point and floating-point
| arithmetic would not expect the "to_i" operator to do _rounding_.  That
| operation is defined as one which performs _truncation_.  People who
| never learned these numerical concepts or who incorrectly expect
| truncation operators to do rounding should not be writing code to handle
| the navigation of Mars landers.

You misunderstand me then. I never expected that. The original message in this 
thread asked about that, but this thread left that long ago and criss-crossed 
with a second thread, in which we got on to a particular bugaboo...let me 
find it... see ruby-talk:116739

| If someone wants the two floating-point numbers 100.00 and 9.95 to be
| multiplied together to yield the integer result 995, then rounding will
| _have to_ be performed.  In order to do that, different procedures,
| other than (100.00 * 9.95).to_i, need to be used.  For example, one of
| many ways to do it is this:
|
|   irb(main):001:0> sprintf('%.0f', 100.00 * 9.95).to_i
|   => 995
|
| That's because the "%f" format for sprintf is _defined_ as specifying
| that rounding gets done when it converts a floating-point number to its
| string representation.  The to_i operator alone is not defined in that
| way.
|
| There are other algorithms and packages that already are in existence
| that will also perform rounding.  In other words, we already live in
| this "better world".  Someone who needs to use representations of
| decimal numbers that are forced into a fixed precision should learn that
| these various algorithms and packages exist, and they should learn how
| to make use of them.
|
| For example, see the "mathx" package in RAA.  Also, see the BigDecimal
| and Rational packages, which already have been mentioned in this
| thread, I believe.

Yes, I'm aware of these. Thank you. If I were to sum up my point I think it 
would be this: We are more than advanced enough to not have to use poor 
representations of numbers that return obvious errors (as in the above given 
alternate thread). Having to account for all the possible gotchas in variant 
algorithms is a large waste. Yes, we had to deal with them for some time b/c 
of technological restraints and learning curves, (and academic circles will 
continue to explore them) but at this point it really shouldn't be turning up 
in high level languages. As the example shows, we are not yet in this 
particular "better world".

T.