Floating point bug?

[Jeff Schwab]

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.