On 1 Nov 2011, at 2:52pm, Richard Hipp wrote: > This is why you are admonished to never compare floating point numbers for > equality - in any system, not just in SQLite.
And in this case, the most rigid and correct solution is to hold those numbers as integers. So given the numbers you supplied were > Id|base|thick > 89|281.04|0.03 > 90|282.09|1.05 > 91|283.11|1.02 > 92|290.08|6.97 my guess is that you should multiply those measurements by 100. Alternatively you can simply expect to lose the precision of the last digit. In other words, if the database holds a number that looks like abc.de and 'e' is a 7 in this case, you can expect that comparisons might interpret this as a 6, 7 or 8 randomly, and plan your application accordingly. Which of the two above solutions you choose depends on the nature of your system. The first gives you technically correct answers but requires reformatting of numbers when they're input and output. The second is simpler and requires less programming but requires users to understand 'slop'. Simon. _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
