Nico, >There is one thing that makes numerical support in RDBMSes important: >aggregate functions. > >Aggregate functions are critical because they allow one to do much >analysis at the data source, instead of having to transport it >elsewhere for analysis.
I agree with you, totally. Read me again: I never said FP support in SQLite or any DBMS is useless, just that complete support and control of FP is not in the possibility of SQLite (and probably not achieved in any other DBMS). >Storing them is not the issue. Getting them as results of arithmetic >operations in SQL statements is the issue. Agreed again. But which kind of computation, statistical analysis or other common operation does produce NaNs routinely? If you get NaNs in computing a variance or some other fancy (but basic) chained computation, then your data is at fault. No, not your data: your model. Before embarking in any computation you absolutely need a clear idea of the limits it may trepass either as a final result or in route: precision, accuracy, ... Remember a recent thread here about native SQLite Round() and its varying results depending on the system used? Just such a "naïve' Round(), without all the bells and whistles of the many rounding options that 754 & al support /*for all operations*/. 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! 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! I encourage anyone interested in learning where the dark corners of FP lie to read this document: http://hal.archives-ouvertes.fr/docs/00/28/14/29/PDF/floating-point-article.pdf Since such a "simple" function like round() is non-portable how can one expect not "full" but only "reasonable" compliance with things like NaNs in a product like SQLite, over the full range of hardware, OS, compilers (+ releases + options), wrappers, application language, ... it will be used on? That's plain impossible. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
