I didn't see this go through, so I'm sending it again. I got an Alexa spam, so maybe that's part of it.
I ran 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; 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-boun...@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.
