On Dec 10, 10:46 am, dbd <d...@ieee.org> wrote: > On Dec 7, 12:58 pm, Carl Banks <pavlovevide...@gmail.com> wrote: > > > On Dec 7, 10:53 am, dbd <d...@ieee.org> wrote: > > > ... > > > You're talking about machine epsilon? I think everyone else here is > > talking about a number that is small relative to the expected smallest > > scale of the calculation. > > > Carl Banks > > When you implement an algorithm supporting floats (per the OP's post), > the expected scale of calculation is the range of floating point > numbers. For floating point numbers the intrinsic truncation error is > proportional to the value represented over the normalized range of the > floating point representation. At absolute values smaller than the > normalized range, the truncation has a fixed value. These are not > necessarily 'machine' characteristics but the characteristics of the > floating point format implemented.
I know, and it's irrelevant, because no one, I don't think, is talking about magnitude-specific truncation value either, nor about any other tomfoolery with the floating point's least significant bits. > A useful description of floating point issues can be found: [snip] I'm not reading it because I believe I grasp the situation just fine. But you are welcome to convince me otherwise. Here's how: Say I have two numbers, a and b. They are expected to be in the range (-1000,1000). As far as I'm concerned, if they differ by less than 0.1, they might as well be equal. Therefore my test for "equality" is: abs(a-b) < 0.08 Can you give me a case where this test fails? If a and b are too far out of their expected range, all bets are off, but feel free to consider arbitrary values of a and b for extra credit. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
