Hi All,
Here's my 2p...
on XP and VC++ (for my sins!)
The round function works.
sqlite_column_double() returns 98926650.5
The '000001' on the end is introduced by calling sqlite_column_text
(in shell.c).
This results in reaching the line
sqlite3_snprintf(NBFS, z, "%!.15g", pMem->r);
in sqlite3VdbeMemStringify.
This resolves down to calling a function vxprintf, which has the following line:
while( realvalue>=10.0 && exp<=350 ){ realvalue *= 0.1; exp++; }
When this line is reached, realvalue has value 98926650.5 and exp value 0.
realvalue then goes the following values during the loop:
9892665.0500000007
989266.50500000012
98926.650500000018
9892.6650500000032
989.26650500000039
98.926650500000051
9.8926650500000051
exp finishes at 7
Note the 'error' added in by the successive multiplications is 0.000000051
When the rounding value (calculated earlier) is added to realvalue,
the 15th digit is now 1, and therefore within the requested precision.
The call to sqlite3_snprintf() asks for 15 digits precision, hence the
'000001' gets displayed in the result to the shell.
To summarize, the successive multiplication in vxprintf introduces a
large enough error that it is representable by the precision requested
by sqlite_column_text().
Interestingly, if the line is changed to
while( realvalue>=10.0 && exp<=350 ){ realvalue /= 10; exp++; }
then the accumulated error is less, and the correct value is printed.
Of course, this change may break other builds.
One wonders why XP/VC++ produces such a large error in its floating
point manipulations that appears to be avoided by other compilers.
Rgds,
Simon
On 05/09/07, Doug Currie <[EMAIL PROTECTED]> wrote:
> On Wednesday, September 05, 2007 Arjen Markus wrote:
>
> > Doug Currie wrote:
>
> >>I suspect the bug is in the functions that convert between string and
> >>double; that's why I keep harping on Steele and White's (and
> >>Clinger's) PLDI 1990 papers. What I don't know is why this bug appears
> >>in the binary from sqlite.org but not in the version I build myself
> >>with gcc 3.4.5 from SQLite version 3.4.2 source.
> >>
> >>
> >>
> > The implementation of that algorithm is far from trivial. It actually
> > requires the
> > use of an arbitrary-precision library (or so at least is my understanding).
>
> Yes, in some cases big integers are needed. In extreme cases, e.g.,
> denormalized numbers, up to 160 bytes may be required.
>
> I have implemented these algorithms, twice, but for employers with
> proprietary programs. The algorithms are also implemented in glibc
> based on high quality code from David Gay (Bell Labs, Lucent, Sandia,
> Netlib), available with a BSD license at
> http://netlib.sandia.gov/fp/index.html
>
> e
>
> --
> Doug Currie
> Londonderry, NH, USA
>
>
> -----------------------------------------------------------------------------
> To unsubscribe, send email to [EMAIL PROTECTED]
> -----------------------------------------------------------------------------
>
>
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
