So here is the epsilon value for various scales of double precision floating
point numbers (scale is the absolute base10 exponent):
scale= 0 epsilon= 2.220446049250313e-16
scale= 1 epsilon= 1.7763568394002505e-15
scale= 2 epsilon= 1.4210854715202004e-14
scale= 3 epsilon=
Thanks, never in the deepest corner of my mind would I have expected it to be
integer only. It was only reading this thread and wondering why no one had
answered "just do x - x % .001" that made me go check it out. Fortunately I
haven't used it any queries.
Is this an SQL standard? A C
Thank you M. Medcalf for your nice explanation.
In my first post, I gave half of the used solution : when storing a
"truncated value", eventual remaining digits are allso, separately,
stored as a whole integer.
Both parts are reassembled later when needed (i.e. when doing set
agregation).
Confirmed. Thanks Clemens!
Option -interactive does work on named pipes as suggested, by keeping the
file handle open.
Below is a working reference procedure in bash for input and output if
anybody is interested.
On terminal 1:
$ mkfifo /tmp/slsh_in
$ mkfifo /tmp/slsh_out
$ ./sqlite3
petern wrote:
> $ echo "SELECT ('Shouldn''t SQLite shell continue interactively after
> processing this statement?')msg;" >/tmp/slsh_in
> $
>
> Results at first terminal after echo line is sent from second terminal:
>
> $ #Interactively run sqlite3 from named pipe.
> $ mkfifo /tmp/slsh_in
> $
This test case is peformed using two bash terminal sessions.
(1) At the first terminal:
$ #Interactively run sqlite3 from named pipe.
$ mkfifo /tmp/slsh_in
$ ./sqlite3 -interactive /tmp/slsh_in
$
Results at first terminal after echo line is sent from second terminal:
$ #Interactively run
The issue here is that you are "truncating" using Base10 (Decimal) but the data
is stored in Base2 Floating Point. Therefore you will always get approximate
results and never an exact one. On modern computers floating point arithmetic
is defined in such a way as to represent approximations
7 matches
Mail list logo