On 9/30/05, Ralf Junker <[EMAIL PROTECTED]> wrote: > > Quite right, but even with explicit typing there are cases where SQLite3 > can not be instructed to store REAL numbers as REALs: > > C:\>sqlite3 num.db3 > SQLite version 3.2.1 > Enter ".help" for instructions > sqlite> CREATE TABLE i (a INTEGER, b INTEGER); > sqlite> INSERT INTO i VALUES (5, 2); > sqlite> SELECT a / b FROM i; > 2 > sqlite> INSERT INTO i VALUES (5.0, 2.0); > sqlite> SELECT a / b FROM i; > 2 > 2 > > Even though the 2nd insert explicitly types 5.0 and 2.0 as REALs, they are > stored as INTEGERs internally and resuls in incorrect calculations (the very > last number should be 2.5 and not 2).
In that case it did what it was instructed to do. The type was integer so it converted. Summming up: Observations show that SQLite3 behaves inconsistent when > storing and/or calculating numbers as INTEGERs or REALs. The point I am > personally worried about is not so much the storage side of things but the > calculation errors resulting from it. Since it behaves in predictable ways I don't believe inconsistency is a big problem. Inconsistency is the only constant I've found in life! It's only inconsistent on one operation, storing integers in a real type. If you code with a rule of thumb to always insert with something like "insert into t values( round(x) );" then you will have no problems. I would like to propose the resolve this inconsistency as follows: > > That would make sqlite math inconsistent with math as performed by computer languages. I don't see that as an improvement. --- The Castles of Dereth Calendar: a tour of the art and architecture of Asheron's Call http://www.lulu.com/content/77264
