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?  

sqlite-users mailing list

Reply via email to