> On Oct 17, 2016, at 2:12 AM, Quan Yong Zhai wrote:
>
> Or after prepare “ INSERT INTO test VALUES(?) “
> Bind_text “62.027393”
> Bind_double 62.027393
>
> In all the four situation, the value insert into foo field is binary
> identical, it’s a 8-bytes REAL value.
I suspect the
ite mailing list
Subject: Re: [sqlite] A possible double bug?
I can’t reproduce the problem,
http://sqlite.org/datatype3.html#type_affinity
“When text data is inserted into a NUMERIC column, the storage class of the
text is converted to INTEGER or REAL (in order of preference) if such
convers
On 10/17/2016 08:29 AM, Quan Yong Zhai wrote:
"The database file format is cross-platform - you can freely copy a database
between 32-bit and 64-bit systems or between big-endian and little-endian
architectures.
Quote:
"In your machine, implementation, and SQLite installation the
two value rep
.org>
主题: Re: [sqlite] A possible double bug?
On 10/17/2016 07:12 AM, Quan Yong Zhai wrote:
> I can’t reproduce the problem,
As it has already been pointed out, this is normal for floating point
arithmetic. In your machine, implementation, and SQLite installation the
two value representati
On 10/17/2016 07:12 AM, Quan Yong Zhai wrote:
I can’t reproduce the problem,
As it has already been pointed out, this is normal for floating point
arithmetic. In your machine, implementation, and SQLite installation the
two value representations may be identical, while in others it may not be
I can’t reproduce the problem,
http://sqlite.org/datatype3.html#type_affinity
“When text data is inserted into a NUMERIC column, the storage class of the
text is converted to INTEGER or REAL (in order of preference) if such
conversion is lossless and reversible”
So after “create table test (fo
I’d say the mistake here is converting a double to a string before inserting it
into the database. Any time you convert between floating point and decimal (or
vice versa) you can lose accuracy, and are not guaranteed round-trip fidelity.
(0.1, 0.01, 0.001, etc. do not have finite-length exact re
On Sunday, 16 October, 2016 12:03, Victor Evertsson
wrote:
> I was wondering about the different behavior of inserting a Double as a
> String vs as a value with a prepare statement in C.
> Consider an example when the value: 62.027393 is inserted as a String and
> as value with a prepared sta
Hi,
I was wondering about the different behavior of inserting a Double as a
String vs as a value with a prepare statement in C.
Consider an example when the value: 62.027393 is inserted as a String and
as value with a prepared statement, for instance:
"CREATE TABLE test (foo REAL)"
"INSERT INTO
9 matches
Mail list logo