1 |
On Sat, Aug 22 2015, Mike Gilbert wrote: |
2 |
|
3 |
> On Sat, Aug 22, 2015 at 1:32 PM, Alan McKinnon <alan.mckinnon@×××××.com> wrote: |
4 |
>> I can tell you that equality comparisons on floats are problematic, and |
5 |
>> always will be due to how they are stored (double-precision floats, |
6 |
>> inhernetly inexact). This is not a "problem" per se, it's a systemic |
7 |
>> side effect of how our computers represent floats i.e. you can't "fix" |
8 |
>> it as there is nothing to fix |
9 |
> |
10 |
> It's not that floats are inherently "inexact"; it really has to do |
11 |
> with trying to represent a base-10 number in a data structure designed |
12 |
> to hold a base-2 number. |
13 |
> |
14 |
> If your number can be represented by some multiple of a power of 2, |
15 |
> equality comparisons will work. If it cannot be, it has to be stored |
16 |
> as an approximation. |
17 |
|
18 |
I am not sure exactly what you mean. Every number is a multiple of a |
19 |
power of 2, in particular a multiple of 2^0=1. |
20 |
|
21 |
Also |
22 |
|
23 |
2^0 + 2^1 + 2^2 + ... 2^100 != 2^100 + 2^99 + ... + 2^1 + 2^0 |
24 |
|
25 |
on a 64-bit machine assuming left to right addition. |
26 |
|
27 |
This example does not use floating point for that use negative exponents |
28 |
|
29 |
2^-0 + 2^-1 + ... + 2^-100 != 2^-100 + ... + 2^-1 + 2^-0 |
30 |
|
31 |
In general for adding many positive floating point numbers, it is better |
32 |
to add the small numbers first. |
33 |
|
34 |
One more example. Assume a DECIMAL floating point machine with two |
35 |
digits of mantissa and say 20 digits of exponent. This machine cannot |
36 |
express 101 since that requires 3 digits of mantissa. Then |
37 |
|
38 |
100 + 1 + 1 + ... + 1 (100 1s) = 100 |
39 |
|
40 |
1 + 1 + ... + 1 + 100 (100 1s) = 200 |
41 |
|
42 |
allan |