(Edited in light of Igor's sharp-eyed observation.) Once you fix the blunder Igor mentions, and continue to observe imprecision: In the programming language [Scheme](https://en.wikipedia.org/wiki/Scheme_\(programming_language\)), floating point types are considered "inexact". Among other things, this means that when results are computed in different ways that *appear* to be mathematically equivalent [a], the results may not be equal. [a. Even though many languages have expression syntax that resembles mathematical notation, they are specifying operations that are only resemble mathematical operator definitions. ] You may be unaware that on many computers, intermediate terms in expression evaluation can be held with a higher precision than values that are stored. SQLite's execution engine does not exploit that possibility; instead each result of a binary operator is stored without such higher precision. This means that its floating point inexactitude will manifest slightly differently than would be seen where such results are left in and reused from higher precision registers within the floating point arithmetic unit. This is the most likely factor behind the minute discrepancies you have focused upon. That all said, I see a way to improve matters here: Given that the requirement is unstated or nonexistent, and accuracy already achieved is typical of a properly operating computer, declare it "Good Enough". That is an honored term of art in engineering disciplines. If you wish to embark on a quest for unbounded accuracy, there are software packages which do not impose the usual limits on numerical precision. Most of them impose only memory usage limits, but those can be quite expansive today.