On Wed, 28 Jan 2015 23:09:21 +0000 Simon Slavin <slav...@bigfraud.org> wrote:
> > This is a bit of a speculative question related to a problem I'm > > having - are there legal values of a C++ double that would get > > truncated when written into and read from an SQLite database? > > In theory there should be no problem here. > > C doubles have 15 to 16 digits of precision. > > In SQLite databases, numbers which can't be stored as integers are > stored as IEEE 754-2008 64-bit floating point numbers, sometimes > known as 'binary64'. These give 15 to 17 digits of precision. We can make stronger statements than that, can't we? It's not like there's some mystery about it: database and memory share a single floating-point format. If the caller uses _bind_double and _column_double, he's storing and fetching a 64-bit double. SQLlite's only job is to collect those 8 bytes, store them, and return them unmolested. It has no private definition of "double", offers no conversion between different representations of double. The bit pattern -- IEEE 754-2008, as you say -- is defined by the *hardware*. That format is shared up and down the stack, regardless of whether or not SQLite and the application were compiled using the same compiler. (That's no 100% true, of course. Is anyone seen SQLite running on a VAX? Has it ever been done?) So I think it's a bit disingenuous to speak in terms of digits of precision. Application and library alike share a single IEEE double-precision floating point representation. There's no reason to think, if the data are provided in binary form, that they won't be returned in the identical form absent an explicit conversion. If that's not so, I'd sure like to know why. I'm faintly surprised NaNs can't be stored, too. Why should SQLlite interpret them if they're bound to a double? --jkl _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
