Zentrader wrote: > I disagree with this statement > <quote>But that doesn't change the fact that it will expose the same > rounding-errors as floats do - just for different numbers. </quote> > The example used has no rounding errors.
I think we're using the term "rounding error" to mean different things. If the value 1/3 is represented as a finite sequence of threes divided by a power of ten (e.g. 0.3333333333333333333333333333), then it is actually representing a different value than the original 1/3 (3333333333333333333333333333/10000000000000000000000000000). This is what most of us mean by "rounding error." There are data types than can represent rational numbers exactly, such that 1 / 3 * 3 = 1. > For anything less that 28 > significant digits it rounds to 1.0. I'm not sure what you mean here. Do you mean that Decimal can represent any sequence of up to 28 decimal digits without any loss in precision? No one disputes that. > With floats 1.0/3 yields > 0.33333333333333331<-- on my machine. Right, that is != 1/3. But if the last digit were a 3, the number still would not be 1/3, only a different approximation of it. > Also you can compare two > decimal.Decimal() objects for equality. With floats you have to test > for a difference less than some small value. A small margin of error (epsilon) is required for both Decimal and floats. Both of these data types have "floating points;" they just use different radixes. Particular sorts of rounding-errors have become acceptable in base-10 arithmetic within certain (mainly financial) contexts, so Decimal is preferable for calculations in those contexts. For the same reason, a major U.S. stock exchange switched from base-2 to base-10 arithmetic a few years ago. There's nothing inherently more accurate about base-10. > BTW, a college professor > who also wrote code for a living made this offhand remark "In general > it is best to multiply first and then divide." Good general advice. It is best to keep track of how many significant digits remain in whatever base is being used. "M before D" may help preserve sig. digits, but it is not a substitute for knowing how much error each calculation introduces. -- http://mail.python.org/mailman/listinfo/python-list