Allow me to add a humble bit to what Jay just posted. SQLite, as well as most other RDBMS around, allow you to perform FP calculations in SQL statements. I assume no-one imagines an extended FP fine-grain support of hundreds of computation options and status reporting be part of SQL or SQLite. It's just not the purpose of SQL and DBMSs in the first place.
Now if you take scientific computations (there I mean with all fine-grain detail support) out of the SQL statements and just look at the engine as a mean to store, organize, query data (scientific or not), SQLite still offers much flexibility to you. You have a DOUBLE column where you need to store NaN? Go ahead and store 'NaN' in offending rows. You need to store +Inf, -Inf, flag denormals, a.s.o, just do it by storing such values or flags as BLOBs, TEXT or whatever type you find most appropriate. Look, I'm a very happy user of Mathematica and some other math packages, and I sometimes need to store incredibly large values without loss of arbitrary precision. I don't expect the smallest part of Mma being built into SQLite to perform computations. OTOH, SQLite offers me the opportunity to do so without having to find fragile workarounds to get rid of limitations of a fixed, strongly-type system. Should you ever have to perform those fine-grain computations with all nickpicking details, then you still can do so either in your application or write an extension with all the functions you need, without being limited to, for instance, the "naïve" rounding function included in SQLite (@DrH: I've no grief here). You can bring the whole Intel decimal FP arbitrary precision library if you whish and still keep on using SQLite for what it really is. My 2 cents _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
