Re: [sqlite] Question regarding handling of infinity values in ROUND
I noticed that this has been fixed now ( https://www.sqlite.org/src/info/db9acef14d492121). Thanks! Best, Manuel On Fri, May 10, 2019 at 12:09 PM Manuel Rigger wrote: > Hi everyone, > > I was surprised by how the ROUND function handles "Inf" REAL values. > > A REAL infinity value can be created by using an overly-large number: > > SELECT 1e5000; -- Inf > > When casting infinity to an integer value, the largest integer is > returned, which seems intuitive to me: > > SELECT CAST(1e5000 AS INT); -- 9223372036854775807 (2^63 - 1) > > However, the ROUND function always converts Inf to zero, which is somehow > surprising, since a >= b does not imply ROUND(a) >= ROUND(b) (which > contrasts the behavior of a cast): > > SELECT 1e500 >= 1, CAST(1e500 AS INT) >= CAST(1 AS INT), ROUND(1e500) >= > ROUND(1); -- 1|1|0 > > Is this deliberate? Would it make sense to let ROUND(Inf) = Inf (and > ROUND(-Inf) = -Inf))? > > Best, > Manuel > > > > > > ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] Question regarding handling of infinity values in ROUND
Hi everyone, I was surprised by how the ROUND function handles "Inf" REAL values. A REAL infinity value can be created by using an overly-large number: SELECT 1e5000; -- Inf When casting infinity to an integer value, the largest integer is returned, which seems intuitive to me: SELECT CAST(1e5000 AS INT); -- 9223372036854775807 (2^63 - 1) However, the ROUND function always converts Inf to zero, which is somehow surprising, since a >= b does not imply ROUND(a) >= ROUND(b) (which contrasts the behavior of a cast): SELECT 1e500 >= 1, CAST(1e500 AS INT) >= CAST(1 AS INT), ROUND(1e500) >= ROUND(1); -- 1|1|0 Is this deliberate? Would it make sense to let ROUND(Inf) = Inf (and ROUND(-Inf) = -Inf))? Best, Manuel ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] SQLite with single writer on Windows network share
On Fri, May 10, 2019 at 4:40 AM Warren Young wrote: > Bedrock is based in part on the Paxos algorithm, another major advance in > distributed computing, and another of Leslie Lamport’s brainchildren: > > https://en.wikipedia.org/wiki/Paxos_(computer_science) In the same vein, there's also Raft [1] (Raft is a consensus algorithm designed as an alternative to Paxos) which is used by RQLite [2] (The lightweight, distributed relational database built on SQLite). FWIW, --DD [1] https://en.wikipedia.org/wiki/Raft_(computer_science) [2] https://github.com/rqlite/rqlite ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Feature request, sqlite3_stmt_action
Working with RediSQL another use case comes to mind for some implementation of the interface we were discussing. How to detect SELECT statements that return empty. SQLite simply return SQLITE_DONE in all cases, and it makes impossible to know if it is an empty SELECT or something else. A possible solution that I tried was to check if the query executed was read_only, unfortunately also things like `CREATE TABLE IF NOT EXISTS foo(a,b);` are read_only if the table do exists. -- Sent from: http://sqlite.1065341.n5.nabble.com/ ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
