Shane Harelson: > Under the covers, when the second term to ROUND(X,y) is omitted, SQLite adds > 0.5 and then truncates. Because of floating point precision, some numbers > can not be represented exactly... causing the odd rounding you saw in your > examples.
I've just had a look "under the covers", and indeed it seems that SQLite has its own printf implementation. Makes sense, as I think the C standard itself is also implementation-defined in this case, and this might be the kind of thing that SQLite coders want control over. It was hasty to conclude that round-to-even is the rule, as one more example shows: sqlite> select round(40226.5); 40227.0 I think the 40223.5 case is just an example of binary/decimal floating point incompatibility. As Kernighan and Plauger put it: "Floating-point numbers are a lot like sandpiles: Every time you move one you lose a little sand and pick up a little dirt." I'm a little surprised that it's going wrong with a number ending in 0.5 though, I'd have thought that that would be expressible perfectly in binary without loss. I don't know enough about it though. Phil Hibbs. -- Don't you just hate self-referential sigs? _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
