From: Lloyd Zusman Date: 2004-10-31T05:31:51+09:00 Subject: Re: Rounding error ... [remainder of huge subject line truncated] "trans. (T. Onoma)" writes: > 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 > > [ ... ] > > 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". What technological constraints are you talking about? The constraints that determine the rounding/truncation/etc. behavior of numbers in computers are determined the nature of computers themselves: computers do not have infinte memory. Therefore, any number that can be represented in a computer, be it fixed point, floating point, rational, or some other, possibly yet-to-be-defined format will _always_ be subject to truncation, rounding, or other forms of approximation when it is used in calculations. You can't get away from that. The question, therefore, is not how to eliminate truncation or rounding, but rather, how to intelligently perform these approximations when they are necessary. As Steven Jenkins has mentioned here, high-level research into numerical methods is actively taking place, and it has been going on since computers were invented ... actually, since before that time. The problems you raise, if you think about them a bit, do not lend themselves to simplistic solutions. For example, explain to me an algorithm which will "properly" do rounding in all of the following cases. How many decimal places will the result have, and will there or will there not be any rounding? 1. 100 * 9.95 2. 100 * (29.85 / 3) 3. (100 * 29.850) / 3.0 6. 1 / 3 7. 1 / 3.0 8. 1 / sqrt(9) etc. etc. What is the intention of the programmer in each case, and what _should_ the answer be (in terms of number of decimal places, rounding behavior, truncation behavior, etc.). -- Lloyd Zusman ljz@asfast.com God bless you.