L.S.
As per earlier posts: I'm using Sqlite on an Arm architecture without FP-unit
running a kernel that has FASTFPE built in.
After solving the mixed-endian issue, it turns out there's yet another problem
when one is looking at floating point numbers in a text representation......
A number like 1.24, which is not exactly representable, will be presented
still by Sqlite as '1.24', but the underlying 'magic' fails in the situation
of FASTFPE, simply because the assumptions made on accuracy are
obviously 'wrong' then ;(
* a regular 64 bit float has 52+1 bits for the mantissa and thus an estimated
number of accurate digits of log(2^53) ~= 15.955 => 16 digits
* a fastfpe float has 32+1 bits for the mantissa and thus an estimated number
of accurate digits of log(2^33) ~= 15.955 => 10 digits
So, I've been trying to find the locations for this 'magic' and came up with
the following two:
src/printf.c:158 contains et_getdigit() with line 161:
if( (*cnt)++ >= 16 ) return '0';
in which I'd need to change the 16 into 10.
src/vdbemem.c:201 contains sqlite3VbdeMemStringify() with line 220:
sqlite3_snprintf(NBFS, z, "%!.15g", pMem->r);
in which I'd need to change the 15 into 9
Changing these values seems to work out fine (and it returns '1.24' again
instead of something like '1.23999999962718'), but since I'm not thát known
with sqlite's source, I'm wondering if there are more locations that have
some hardcoded notion on float-accuracy...
DRH, any hints.......?
I'll wrap the changes up in a patch using some define like SQLITE_FASTFPE or
something, unless DRH has a different idea ;)
--
Best,
Frank.
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
