On 1 Nov 2011, Richard Hipp wrote: > Floating-point numbers are approximations. There is no way to represent > 290.08 or 6.97 or 283.11 in binary. The closest you can get to these > numbers using IEEE doubles is:
> 290.07999999999998408384271897375583648681640625 > 6.96999999999999975131004248396493494510650634765625 > 283.1100000000000136424205265939235687255859375 > And to compound the difficulty, SQLite does not attempt to get that close, > as doing so requires infinite-precision integer math in the worst case and > a noticeable performance hit. SQLite, therefore, goes for a rougher > approximation and settles for 14 significant digits. Are you familiar with David Gay's fast, accurate & free strtod implementation (http://www.netlib.org/fp/dtoa.c)? It should be as fast as the SQLite implementation in util.c for strings with fewer than 9 digits, and it will always return the correctly rounded result. Having the text parser accurately handle floating-point input is important to my company. I have permission to donate my time to integrate his code and provide a suite of test cases, if you're interested. Sincerely, Bob Burger _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
