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 >
