On Wed, Sep 9, 2015 at 9:47 PM, R.Smith <rsmith at rsweb.co.za> wrote:
> > On 2015-09-09 05:19 PM, Constantine Yannakopoulos wrote: > >> On Wed, Sep 9, 2015 at 4:54 PM, Igor Tandetnik <igor at tandetnik.org> >> wrote: >> >> ?Out of curiosity, doesn't this also apply also to numeric (real number) >> comparisons since SQLite3 uses IEEE floating point arithmetic?? >> > > IEEE Float comparisons do not work this way - you are more likely to find > the opposite: two numbers that seem to be near perfectly equal might fail > an equality test. > ?That is the problem. There are cases where two numbers that come out of different calculations? (especially if a division is included) are expected to be equal but they fail the equality test. A classic case is when you distribute an amount (e.g. a total) among several rows using a certain column as weight and you expect the sum of the distributed amounts to be exactly equal to the original total but it is not. > On Wed, Sep 9, 2015 at 7:47 PM, Igor Tandetnik <igor at tandetnik.org> wrote: > What aspect of IEEE floating point arithmetic makes comparisons unsafe, in > your opinion? Given two IEEE numbers (NaNs and INFs excepted), the > comparison would only ever declare them equal if their representations are > bit-for-bit identical; it doesn't play "close enough" games. What again > seems to be the problem? > ?OK, I was under the impression that SQLite ?used an epsilon comparison to avoid the aforementioned case. Obviously I was wrong. Sorry. As I said, no problem, just curiosity.
