On Wed, 16 Dec 2015 20:33:40 +0200 R Smith <rsmith at rsweb.co.za> wrote:
> > Ok this does not work of any scale of numbers. But a solution with > > integers neither does > > I think the bit that Keith tried to highlight is that we should > always refrain from storing errors. Keith recommended against storing *rounded* values. If you store $0.30 in SQLite as REAL, you store a binary approximation. It's a fine thing to keep unless you care about picodollars. > Calculated errors are fine because we can at any time revisit the > calculation procedures, we can refine and perhaps opt for more > significant digits - but we can ALWAYS guarantee the accuracy-level > of the calculated result. However, storing wrong values (or let's > call them "approximate" values if you like) is pure evil. I'm not sure what you mean. There's no problem storing a C double from memory and later fetching it. The same 64 bits pass through the interface unchanged. (Well, maybe not the *same* bits, but who can tell?!) Once replaced back in C memory, the computation can resume where it left off unaffected. What you usually don't want to do is compute based on rounded numbers. If you store a rounded number to the database, you may lose information. Even if you don't -- even when the rounded number is the right one -- such errors as accumulate at the edge of accuracy normally wind up not mattering. That's why C does all computation in double precision, even when the operands are single-precision. The opposite mistake -- losing information -- can easily lead to results that are spectacularly wrong. --jkl
