On Wed, Oct 28, 2015 at 3:52 PM, SQLite mailing list < sqlite-users at mailinglists.sqlite.org> wrote:
> On 28 Oct 2015, at 10:34pm, SQLite mailing list < > sqlite-users at mailinglists.sqlite.org> wrote: > > This explains the deficiency in the SQLite print function, but it doesn't > > have to be that way. > > I'm with a previous poster. SQLite is primarily a database system. Its > primary jobs are storage and retrieval. It shouldn't really be used to > print at all and putting unusual effort into its print functions may not be > wise. > > However, I would support improvement in its floating point calculations, > including implementing 'slop' in testing for equality. This is not only > for use when expressions include the equal sign, but also for cases where > comparing two numbers is done in important internal operations, like > checking that primary keys do not include duplicate entries. > IMHO, this kind of thing can be subtle and full of bugs. For purposes of a value literally typed as a float, I think using the IEEE 754 value as a blob is the right thing to do. In addition, it would be reasonable to have a function for comparison including an epsilon. That wouldn't make sense for indices, though, because of the problem where two values may not be within epsilon of each other, but they may be within epsilon of a third, so insert success becomes order dependent (in one order, 1 of 3 succeeds, in the other order 2 of 3 succeed). Actually, I think I'd be willing to forbid UNIQUE plus REAL entirely :-). -scott (shess at google.com)
