At 23:34 28/10/2015, you wrote: >--- > > Those binary representations can be converted back into precise decimal > > representations, but those decimal representations will not be the > original > > decimal values, because they were translated from decimal strings into > > binary floating-point values and back into decimal strings. > > > -scott > >This explains the deficiency in the SQLite print function, but it doesn't >have to be that way. > >See: Steele, Jr., Guy L., and White, Jon L. How to print floating-point >numbers accurately. In Proc. ACM SIGPLAN ???90 Conf. Prog. Lang. >Design and >Implementation. ACM (White Plains, NY, June 1990), 112?126. ACM SIGPLAN >Noticess 25, 6 (June 1990). > >A retrospective by Steele & White is here: > >http://grouper.ieee.org/groups/754/email/pdfq3pavhBfih.pdf > >I'm not advocating that SQLite add Steele & White's Dragon algorithm, just >pointing out that there are ways to fix the deficiency. > >-- >Doug Currie
While it's possible to (somehow) minimize the issues involved with printing a floating-point value (albeit at high cost), the issue of comparing them as is done in the OP is a pretty different beast. There you have to convert a decimal FP target constant to a binary value stored in FP register or memory storage then perform a comparison. And contrary to Simon, I don't think that: >sqlite> CREATE TABLE t(r REAL PRIMARY KEY,t TEXT); >sqlite> INSERT INTO t VALUES (21.0,'twenty one point zero'); >sqlite> INSERT INTO t VALUES (9.2+7.9+0+1.0+1.3+1.6, 'calculation'); should bark for duplicate PK, since the values are hardly equal in practice. (Else SQLite would indeed raise a dup PK error!) BTW and following an entirely distinct thread: I'd rather filter Alexa out myself using my mail client features. jcd at antichoc.net
