Hello, On 2018-01-22 21:33, Keith Medcalf wrote:
The long and the short of it is that the output of .DUMP is correct.
I would say that the output is ``too correct''. ``.dump'' displays 20 meaningful digits.
Let's look at the 17 meaningful digits. Mantissa divides every exponential range (i.e. range <B^n; B^{n+1}>, which is divided linearly) into 1x2^52 equilengthy segments (binary/double) or 9x10^16 equilengthy segments (decimal/17). The segment represents a rational number.
Every decimal exponential range overlaps 4 or 5 binary exponential ranges. Let's consider decimal exponential range <0.1; 1> -- 17 digits mantissa gives a density of (9x10^16)/(9x10^-1)=10^17 numbers per one.
Let's take the densest binary exponential range which overlaps the above mentioned decimal one: <1/16;1/8> -- 53 digits binary mantissa gives a density of (1x2^52)/(1x2^-4)=2^56=7.2...x10^16<10^17 numbers per one.
Let's find a pair of binary/decimal exponential ranges which overlap each other and a ratio of binary numbers density to decimal numbers density is highest possible (if greater then one, then same binary numbers in the range cannot be represented by 17 digits decimal float).
Believe me or not, (for doubles) the ranges are: decimal: <10^-146;10^-145> -- density: (9x10^16)/(9x10^-146)=10^162 numbers per one; binary: <2^-486;2^-485> -- density: (1x2^52)/(1x2^-486)=2^538=8.99..x10^161<10^162 numbers per one. The ratio < 1. So 17 decimal digits is enough for an exact representation of IEEE64 float.
I suppose that 20 digits is taken from the fact: 64ln(2)/ln(10)=19.2..., however, for 64bit mantissa (long double) it is not enough (to be represented exactly), for 53bit mantissa it is too many. Besides that, 17 digits + one rounding digit fit in i64, while 20 decimal digits do not.
The error of conversion depends on the width of intermediate floats -- not on the width of a integral part. Further increasing of number of meaningful digits does nothing. It is important to use ``long double'' for multiplication. Previous (<= 3.21) implementation of ``AtoF()'' would loose 6 bits (40+ multiplications in the worst case), if it was compiled with a compiler which mapped ``long double'' to ``double''. Integer had 18/19 digits -- it did not helped.
For example, let's look at the first OP's number: 0.05 -- it is 1.999999999999Ax2^-5 => 0.050000000000000003 is enough for an exact conversion. Neighboring numbers are: 1.9999999999999x2^-5 => 0.049999999999999996, and 1.999999999999Bx2^-5 => 0.050000000000000010.
17 digits is also enough for the densest range (<2^-486;2^-485>n<10^-146;10^-145>): 1.FF99999999999x2^-486 => 1.0002594838824945E-146, 1.FF9999999999Ax2^-486 => 1.0002594838824946E-146, 1.FF9999999999Bx2^-486 => 1.0002594838824947E-146.
-- best regards Cezary H. Noweta _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
