Re: [sqlite] .DUMP displays floats differently from SELECT

Hello, On 2018-01-22 13:00, Iulian Onofrei wrote: I have a "REAL" column with float values having up to 2 decimals, and using ".dump" with the latest version incorrectly converts them like this: "0.0" -> "0.0" "0.05" -> "0.050002775" > [...] Did you consider an using of INTEGERs

Re: [sqlite] .DUMP displays floats differently from SELECT

> On Jan 22, 2018, at 10:12 PM, Cezary H. Noweta wrote: > > 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

Re: [sqlite] .DUMP displays floats differently from SELECT

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

Re: [sqlite] .DUMP displays floats differently from SELECT

FYI. There's no need to pin back the whole db version just to get the old style dbdump format. The original dump is available from the distribution as a standalone program here: http://www.sqlite.org/src/artifact/819eb33f6ff788a4 --dbdump.c-- ** If this file is compiled with -DDBDUMP_STANDALONE

Re: [sqlite] .DUMP displays floats differently from SELECT

FYI. There's no need to pin the whole db version back to get original dbdump formatting. The original distribution standalone dump is still available in its full glory here: http://www.sqlite.org/src/artifact/819eb33f6ff788a4 --dbdump.c-- ** If this file is compiled with -DDBDUMP_STANDALONE

Re: [sqlite] .DUMP displays floats differently from SELECT

...@mailinglists.sqlite.org] On Behalf Of Iulian Onofrei >Sent: Monday, 22 January, 2018 05:01 >To: sqlite-users@mailinglists.sqlite.org >Subject: Re: [sqlite] .DUMP displays floats differently from SELECT > >Hi, > >This is clearly a bug, as it outputs incorrect and different outpu

Re: [sqlite] .DUMP displays floats differently from SELECT

I reported this same issue in May 2017 (http://mailinglists.sqlite.org/cgi-bin/mailman/private/sqlite-users/2017-May/072714.html) I too consider this a problem (diffing dumps is one good reason why) but, unfortunately, this was an intentional change by this check-in: [7359fcac] Increase the

Re: [sqlite] .DUMP displays floats differently from SELECT

in the > FAQ http://www.sqlite.org/faq.html#q16 > > > -Original Message- > From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] > On Behalf Of Iulian Onofrei > Sent: Monday, January 22, 2018 7:01 AM > To: sqlite-users@mailinglists.sqlite.org > Subject: R

Re: [sqlite] .DUMP displays floats differently from SELECT

in the FAQ http://www.sqlite.org/faq.html#q16 -Original Message- From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] On Behalf Of Iulian Onofrei Sent: Monday, January 22, 2018 7:01 AM To: sqlite-users@mailinglists.sqlite.org Subject: Re: [sqlite] .DUMP displays floats

Re: [sqlite] .DUMP displays floats differently from SELECT

Hi, This is clearly a bug, as it outputs incorrect and different output from the previous versions. I have a "REAL" column with float values having up to 2 decimals, and using ".dump" with the latest version incorrectly converts them like this: "0.0" -> "0.0" "0.05" -> "0.050002775"

Re: [sqlite] .DUMP displays floats differently from SELECT

Tony Papadimitriou wrote: > Apparently, this was an intentional change by this check-in : > > [7359fcac] Increase the number of significant digits in floating point > literals on ".dump" output from the shell. > > I don't know what problem this change actually solved Scott Robinson already

Re: [sqlite] .DUMP displays floats differently from SELECT

Apparently, this was an intentional change by this check-in : [7359fcac] Increase the number of significant digits in floating point literals on ".dump" output from the shell. I don't know what problem this change actually solved (as in my case it introduced one) but for my own copy I changed

Re: [sqlite] .DUMP displays floats differently from SELECT

ge- From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] On Behalf Of Simon Slavin Sent: Wednesday, May 03, 2017 2:12 PM To: SQLite mailing list Subject: Re: [sqlite] .DUMP displays floats differently from SELECT In a previous message I suggest that behaviour under macOS chang

Re: [sqlite] .DUMP displays floats differently from SELECT

In a previous message I suggest that behaviour under macOS changed between SQLite 3.16.0 and SQLite 3.18.0. I then received information from a lurker who uses Windows 7: SQLite version 3.17.0 2017-02-13 16:02:40 INSERT INTO "xxx" VALUES(1.23); … SQLite version 3.18.0 2017-03-28 18:48:43

Re: [sqlite] .DUMP displays floats differently from SELECT

> -Original Message- > From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] On > Behalf Of Simon Slavin > Sent: Wednesday, May 03, 2017 12:30 PM > To: SQLite mailing list <sqlite-users@mailinglists.sqlite.org> > Subject: Re: [sqlite] .DUMP dis

Re: [sqlite] .DUMP displays floats differently from SELECT

On 3 May 2017, at 3:40pm, Scott Robison wrote: > On May 3, 2017 8:07 AM, "Tony Papadimitriou" wrote: > >> While trying to search/replace some text from an SQLite3 dump I noticed >> that, unfortunately, .DUMP does not produce the exact same numbers as a

Re: [sqlite] .DUMP displays floats differently from SELECT

On May 3, 2017 8:07 AM, "Tony Papadimitriou" wrote: While trying to search/replace some text from an SQLite3 dump I noticed that, unfortunately, .DUMP does not produce the exact same numbers as a plain SELECT on the same values. I know all about expected floating point

[sqlite] .DUMP displays floats differently from SELECT

While trying to search/replace some text from an SQLite3 dump I noticed that, unfortunately, .DUMP does not produce the exact same numbers as a plain SELECT on the same values. I know all about expected floating point inaccuracies, but I don’t see why it should matter in this case as we have