Re: [sqlite] Bug in division?

2014-05-06 Thread Jay Kreibich
On May 6, 2014, at 5:26 PM, Gene Connor <neothreeei...@hotmail.com> wrote: > Subject: Re: [sqlite] Bug in division? > From: j...@kreibi.ch > Date: Tue, 6 May 2014 17:02:02 -0500 > CC: neothreeei...@hotmail.com > To: sqlite-users@sqlite.org > > > The system does no

Re: [sqlite] Bug in division?

2014-05-06 Thread Jay Kreibich
On May 6, 2014, at 4:29 PM, John Drescher wrote: >> Interesting. It makes NO sense to return 0 when dividing two integers. >> > > Never took a C/C++ class? The system does not return 0 any time you divide two integers, but it does return zero for 2 / 4. After all,

Re: [sqlite] Bug in division?

2014-05-06 Thread Simon Slavin
On 6 May 2014, at 1:52pm, RSmith wrote: > I think the OP might be seeing the list via one of those connected sites and > not getting the feedback. Maybe send a direct mail to him. I'll send a personal email to him. Simon. ___

Re: [sqlite] Bug in division?

2014-05-06 Thread Simon Slavin
On 6 May 2014, at 2:06am, Gene Connor wrote: > SELECT DISTINCT 2/4 AS RESULT FROM TABLE; > returns 0 Not a bug. By providing two integer operands you have asked for integer arithmetic, and will get an integer answer. It's something that happens in several

Re: [sqlite] Bug in division?

2014-05-02 Thread Hick Gunter
BTW: The FROM clause is optional in SQLite. It is required only for expressions involving fields. SELECT 2/4 AS RESULT; Will also work, without the overhead of accessing every row of TABLE and performing DISTINCT processing and maybe even without obtaining a lock on the database.

Re: [sqlite] Bug in division?

2014-05-01 Thread Clemens Ladisch
Petite Abeille wrote: > I don’t thing the various ANSI standards have anything normative to > say about what the result of a division should be, merely that there > is a division operator. Indeed: | | | Syntax Rules | | 1) If the declared type of both operands of a dyadic arithmetic |

Re: [sqlite] Bug in division?

2014-04-30 Thread Charles J. Daniels
This is a very common thing. Many programming languages, like C++, do the same thing. So it's not just a SQL thing. --charlie On Wed, Apr 30, 2014 at 7:11 AM, Marc L. Allen wrote: > Not an error. Int/Int uses integer division and results in an integer > number. When

Re: [sqlite] Bug in division?

2014-04-30 Thread Petite Abeille
On Apr 30, 2014, at 8:50 PM, Jay Kreibich wrote: > Given Oracle’s legacy, it might be that “2” defaults to a “numeric” type, > rather than an integer. Indeed, there are no ‘integer’ type per se in Oracle. At least not at the SQL level. But more to the point, I don’t thing the

Re: [sqlite] Bug in division?

2014-04-30 Thread Rob Richardson
I don't know if it's in the SQL standard or not, but the C, C++ and C# languages all act this way. The result of mathematical operations on integers is always an integer. If you want the result to be a floating-point number, you have to force at least one of the operands to be a

Re: [sqlite] Bug in division?

2014-04-30 Thread Jay Kreibich
On Apr 30, 2014, at 1:00 PM, Petite Abeille wrote: > > On Apr 30, 2014, at 2:22 PM, John McKown wrote: > >> PostgreSQL likewise returns 0 for 2/4 and .5 for 2/4.0 . This is likely a >> part of the SQL standard. > > Just to be

Re: [sqlite] Bug in division?

2014-04-30 Thread Petite Abeille
On Apr 30, 2014, at 2:22 PM, John McKown wrote: > PostgreSQL likewise returns 0 for 2/4 and .5 for 2/4.0 . This is likely a > part of the SQL standard. Just to be contrarian, Oracle doesn’t and returns 0.5. Ah! ___

Re: [sqlite] Bug in division?

2014-04-30 Thread John McKown
PostgreSQL likewise returns 0 for 2/4 and .5 for 2/4.0 . This is likely a part of the SQL standard. On Wed, Apr 30, 2014 at 7:11 AM, Marc L. Allen wrote: > Not an error. Int/Int uses integer division and results in an integer > number. When one number is a float,

Re: [sqlite] Bug in division?

2014-04-30 Thread Marc L. Allen
Not an error. Int/Int uses integer division and results in an integer number. When one number is a float, the result becomes a float. I don't know about all SQL varieties, but MSSQL is the same. > On Apr 30, 2014, at 8:04 AM, "Gene Connor" wrote: > > > SELECT