On Fri, Oct 23, 2015 at 9:33 AM, Marc L. Allen <mlallen at outsitenetworks.com> wrote:
> I ram the following code on my ARM processor: > > double c25 = 0.0; > c25 += 9.2; > c25 += 7.9; > c25 += 0.0; > c25 += 4.0; > c25 += 2.6; > c25 += 1.3; > double n25 = 25.0; > It might be illustrative to use the web app at http://babbage.cs.qc.edu/courses/cs341/IEEE-754.html to look at the internal representation of the numbers used in the computation. (Note that below ^ is exponentiation, not xor, and the b suffixed numbers are in binary, so 10 is actually 2 decimal, 11 is 3, etc. Also I'm not rounding numbers just for simplicity.) 9.2 = 1.0010011001100110011001100110011001100110011001100110b * 10b ^ 11b 7.9 = 1.1111100110011001100110011001100110011001100110011010b * 10b ^ 10b 0.0 = 0.0000000000000000000000000000000000000000000000000000b * 10b ^ 00b 4.0 = 1.0000000000000000000000000000000000000000000000000000b * 10b ^ 10b 2.6 = 1.0100110011001100110011001100110011001100110011001101b * 10b ^ 01b 1.3 = 1.0100110011001100110011001100110011001100110011001101b * 10b ^ 00b To add those numbers together, you have to get all the exponents aligned: 9.2 = 1.0010011001100110011001100110011001100110011001100110000b * 10b ^ 11b 7.9 = 0.1111110011001100110011001100110011001100110011001101000b * 10b ^ 11b 0.0 = 0.0000000000000000000000000000000000000000000000000000000b * 10b ^ 11b 4.0 = 0.1000000000000000000000000000000000000000000000000000000b * 10b ^ 11b 2.6 = 0.0101001100110011001100110011001100110011001100110011010b * 10b ^ 11b 1.3 = 0.0010100110011001100110011001100110011001100110011001101b * 10b ^ 11b When you add those together you get: 11.0001111111111111111111111111111111111111111111111111111b * 10b ^ 11b IEEE-754 double precision format requires normalization, so first we need to move the binary point left so that there is a single 1 digit to its left: 1.10001111111111111111111111111111111111111111111111111111b * 10b ^ 100b This format also requires exactly / only 52 digits to the right to the binary point, so we'll drop some digits. There are rounding modes available, but I'm just doing to truncate. 1.1000111111111111111111111111111111111111111111111111b * 10b ^ 100b When converted back to decimal, you get 24.999999999999996 as the result. Because of the detail and complexity of the IEEE-754 standard, there are a lot of details, such as rounding modes and how they are used when converting the decimal values to binary and when converting the binary sum back to decimal. If going to the other extreme, you could get 25.000000000000004 as the result if the above values were handled differently. Regardless, binary floating point can only approximately express our normal concept of numbers (as many others have pointed out in this thread). I just thought it might be illustrative to not just show the final results, but to show how those final results (could) come about. > double c23 = 0.0; > c23 += 9.2; > c23 += 7.8; > c23 += 0.0; > c23 += 3.0; > c23 += 1.3; > c23 += 1.7; > double n23 = 23.0; > > double c21 = 0.0; > c21 += 9.2; > c21 += 7.9; > c21 += 0.0; > c21 += 1.0; > c21 += 1.3; > c21 += 1.6; > double n21 = 21.0; > > My debugger shows the following: > > C25: 2.5000000000000003E+1 (0x4039000000000001) > N25: 25.0 (0x4039000000000000) > C23: 23.0 > N23: 23.0 > C21: 2.1000000000000003E+1 (0x4035000000000001) > N21: 21 (0x4035000000000000) > > The error is down in the least significant bit. > > -----Original Message----- > From: sqlite-users-bounces at mailinglists.sqlite.org [mailto: > sqlite-users-bounces at mailinglists.sqlite.org] On Behalf Of Jim Callahan > Sent: Friday, October 23, 2015 11:19 AM > To: General Discussion of SQLite Database > Subject: Re: [sqlite] Simple Math Question > > Pocket calculators and COBOL used binary coded decimal (bcd) numbers to > avoid the representation/round off issues. But this meant another entire > number type (supported with addition, subtraction and having to be type > checked in functions) in addition to integer and floating point; most found > it easier to use integers to keep track on pennies... > > On Fri, Oct 23, 2015 at 11:05 AM, Scott Hess <shess at google.com> wrote: > > > On Fri, Oct 23, 2015 at 7:39 AM, Dominique Devienne > > <ddevienne at gmail.com> > > wrote: > > > > > On Fri, Oct 23, 2015 at 4:16 PM, Rousselot, Richard A < > > > Richard.A.Rousselot at centurylink.com> wrote: > > > > So I decided to output 1000 digits, because why not? So now I am > > > > more perplexed with all these digits showing it is working the > > > > opposite of > > > how I > > > > expected it. Why is the second set of equations evaluating to a > "yes" > > > when > > > > it is the only one that is obviously NOT equal to the expression??? > > > > > > Indeed, that's puzzling :) > > > > > > Just to be clear, though, how floating-point numbers work is breaking > > your expectations because your expectations are wrong when applied to > > floating-point numbers. Internally, they are base-2 scientific > > notation, so asking for more significant digits in the base-10 > > representation won't help - base-10 fractional numbers cannot always > > be represented precisely in base-2, ALSO base-2 fractional numbers > > cannot always be represented precisely in base-10, so it's like a game > > of telephone where you can end up slightly removed from where you > > started out, even though it seems like it's a simple round trip. > > Since each individual digit cannot be represented perfectly, it > > doesn't matter how many digits of precision you ask for, you'll always > > be able to find cases where it doesn't line up like you expect. > > > > Think of it this way: Find an English sentence, and find an English to > > Japanese translator. Translate each individual word of the sentence > > from English to Japanese, then concatenate the results together. Then > > translate the entire original sentence to Japanese. The results will > > almost never be the same. Then do the same process translating the > > Japanese back to English. Again, the two routes will provide > > different results, _and_ both of those results will almost certainly > > not match the original English sentence. This isn't a reflection of the > translator's abilities at all. > > > > I'm not saying the computer is always right, just that the computer is > > following a very strict recipe with reproducible results. I don't > > mean reproducible like your three examples make logical sense to you, > > the user, I mean reproducible like my Intel box gives the same results > > as my AMD box as my ARM box. If you want to be able to deal with > > fractional decimal values with high fidelity, you either need to > > arrange for base-10 representation (slow, because computers have to > > simulate it), or you have to do your math in shifted fashion (fast, but > can be error prone). > > > > -scott > > _______________________________________________ > > sqlite-users mailing list > > sqlite-users at mailinglists.sqlite.org > > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > > > _______________________________________________ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > > > This email and any attachments are only for use by the intended > recipient(s) and may contain legally privileged, confidential, proprietary > or otherwise private information. Any unauthorized use, reproduction, > dissemination, distribution or other disclosure of the contents of this > e-mail or its attachments is strictly prohibited. If you have received this > email in error, please notify the sender immediately and delete the > original. > _______________________________________________ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > -- Scott Robison
