On Mon, Jun 6, 2011 at 4:58 PM, Jean-Christophe Deschamps <j...@antichoc.net> wrote: > Look at a FP-intensive product like Spatialite (SQLite-based). You'd > probably agree it performs much more complex tasks than average, mean > squares and such. > I'd be very surprised if it used NaN representations!
Sure, if you're just computing average() then you'll not get any NaNs. But you might be dividing averages, or whatever. It's not just the aggregate functions, but what you do with their results. > What I'm saying is that if you (or anyone else) insist on realistic > scientific FP support in SQLite, then you need _way_ more than just > NaNs (signaling or not). FP operations are not even associative in > general and there are too many cases where a given FP number can be > decided to be distinct from itself! No one asks for high precision in DTrace. Depending on the data set, precision may not be important, yet the ability to handle infinities and NaNs might be. (That said, I think it's clear that there's some demand for SQLite3 to be extensible such that extended precision FP libraries could be transparently integrated. Whether that demand will be met is another story. And whether SQLite3's existing, limited FP functionality is sufficient or not for any particular app is yet another story.) Nico -- _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
