If I am not mistaken, you can configure Sqlite to not use floating point at
all. Divisions in such
an environment ought to be truncated integers without additional effort. But I
could be wrong.
--- Dennis Cote <[EMAIL PROTECTED]> wrote:
> I also think we should consider the use of SQLite in
Chris Hanson wrote:
On Nov 2, 2005, at 7:36 AM, [EMAIL PROTECTED] wrote:
Am I alone in thinking that a division operator that does
different things depending on the declared datatype of a
column is an abomination?
I don't think you're alone. I do think you're wrong.
By declaring column a
Brass Tilde wrote:
The problem with the grade-school rule is that, assuming the
last digit is uniformly distributed, you'll be rounding up 5
times out of 9 and rounding down 4 times out of 9.
No, if the last digit is uniformly distributed, then 0 is as likely as any
other. You round down
Henry Miller wrote:
On 11/1/2005 at 21:59 [EMAIL PROTECTED] wrote:
John Stanton <[EMAIL PROTECTED]> wrote:
Users love such a number system because it is natural and works like
the
Arithmetic they learned in Grade School.
I find the idea of dividing two integers stored in binary form
ay, November 02, 2005 7:03 AM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] Proposed 3.3.0 changes. Was: 5/2==2
Well, since you put it that way. May I go one step farther and
request
that this new Dynamic Type also adhere to "Bankers
Rounding" commonly
implemented as BCD i
On 11/2/2005 at 16:13 Eric Bohlman wrote:
>Henry Miller wrote:
>> As for 5/2, my grade school teachers taught me that if I round it at
>> all, the answer is 3, NEVER 2. It is only latter in life that I
>> learned about bankers rounding which sometimes is 2, sometimes 3.
I
>> have never seen
On Nov 2, 2005, at 7:36 AM, [EMAIL PROTECTED] wrote:
Am I alone in thinking that a division operator that does
different things depending on the declared datatype of a
column is an abomination?
I don't think you're alone. I do think you're wrong.
By declaring column a as INTEGER, and column
Brass Tilde wrote:
The problem with the grade-school rule is that, assuming the
last digit is uniformly distributed, you'll be rounding up 5
times out of 9 and rounding down 4 times out of 9.
No, if the last digit is uniformly distributed, then 0 is as likely as any
other. You round down
> The problem with the grade-school rule is that, assuming the
> last digit is uniformly distributed, you'll be rounding up 5
> times out of 9 and rounding down 4 times out of 9.
No, if the last digit is uniformly distributed, then 0 is as likely as any
other. You round down on 0, 1, 2, 3 &
Henry Miller wrote:
As for 5/2, my grade school teachers taught me that if I round it at
all, the answer is 3, NEVER 2. It is only latter in life that I
learned about bankers rounding which sometimes is 2, sometimes 3.I
have never seen a justification for rounding to 2, except for the
the decision on that.
-Original Message-
From: Clark Christensen [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 02, 2005 1:19 PM
To: SQLite List
Subject: Re: [sqlite] Proposed 3.3.0 changes. Was: 5/2==2
> Was this intended as part of the division discussion?
> If so, the original sta
ark Christensen <[EMAIL PROTECTED]>
Sent: Wednesday, November 02, 2005 9:29:13 AM
Subject: Re: [sqlite] Proposed 3.3.0 changes. Was: 5/2==2
On 11/2/05, Clark Christensen <[EMAIL PROTECTED]> wrote:
>
>
> - Original Message
> From: [EMAIL PROTECTED]
> To: sqlite-users
> Please let me restate the proposed change: I desire to change
> SQLite so that it no longer distinguishes between integer and
> real.
Put this way, this seems to be a good idea, provided that there isn't
a performance penalty. Most of the numbers I store in SQLite
databases are small
On 11/2/05, Clark Christensen <[EMAIL PROTECTED]> wrote:
>
>
> - Original Message
> From: [EMAIL PROTECTED]
> To: sqlite-users@sqlite.org
> Sent: Wednesday, November 02, 2005 07:36:58
> Subject: Re: [sqlite] Proposed 3.3.0 changes. Was: 5/2==2
>
> Consider
- Original Message
From: [EMAIL PROTECTED]
To: sqlite-users@sqlite.org
Sent: Wednesday, November 02, 2005 07:36:58
Subject: Re: [sqlite] Proposed 3.3.0 changes. Was: 5/2==2
Consider the following SQL:
CREATE TABLE t1(a INTEGER, b REAL);
INSERT INTO t1 VALUES(5,5);
SELECT a/2
On 11/2/05, Brass Tilde <[EMAIL PROTECTED]> wrote:
> > > floating point operations. If you're creating a very large database
> > > why should you pay for 80 bits (an IEEE float) of storage when 8
> will
> > > do just fine?
>
> > > So don't make the field 10 bytes long, make it only 8. SQLite
> > floating point operations. If you're creating a very large database
> > why should you pay for 80 bits (an IEEE float) of storage when 8
will
> > do just fine?
> > So don't make the field 10 bytes long, make it only 8. SQLite won't
> > care a bit, and will give you the value in whatever
> If it should do division the same way for every operation then you
must
> require the result to be able to represent every possible division
> result. IE the result must be floating point. If you're writing the
inner
> loop for a quake engine there are very good reasons for not wanting to
pay
Am I alone in thinking that a division operator that does
different things depending on the declared datatype of a
column is an abomination?
Absolutely not.
Of course he won't be alone, doesn't make him ( or you ) correct or in fact
incorrect.
I think allowing mathematical operators built
he
"Standard." My contention is, if done properly, the Standard will be
preserved.
Fred
> -Original Message-
> From: Drew, Stephen [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, November 02, 2005 10:01 AM
> To: sqlite-users@sqlite.org
> Subject: RE: [sqlite]
ns of numbers that
don't ad up with the total, and doing other tough things :-)
Fred
FTB2(SS) long ago
> -Original Message-
> From: Brass Tilde [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, November 02, 2005 9:44 AM
> To: sqlite-users@sqlite.org
> Subject: Re: [sqlite] Proposed
:[EMAIL PROTECTED]
Sent: Wednesday, November 02, 2005 11:07 AM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] Proposed 3.3.0 changes. Was: 5/2==2
A quick test here on MSSQL & Oracle:
Microsoft SQL 2000 & SQL 2005 (beta):
create table MATHTEST (
CINT int
vember 02, 2005 4:36 PM
Subject: Re: [sqlite] Proposed 3.3.0 changes. Was: 5/2==2
Consider the following SQL:
CREATE TABLE t1(a INTEGER, b REAL);
INSERT INTO t1 VALUES(5,5);
SELECT a/2, b/2 FROM t1;
From the above SQL, SQLite version 3.2.7 and earlier will return
2|2
If my proposed
On 11/2/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>2.5|2.5
MySQL 5 and MS Access 2003
>2|2.5
PostgreSQL 8 and FireBird 1.5
--
Nemanja Corlija <[EMAIL PROTECTED]>
On 11/2/05, Brass Tilde <[EMAIL PROTECTED]> wrote:
> > Am I alone in thinking that a division operator that does
> > different things depending on the declared datatype of a
> > column is an abomination?
>
> Absolutely not.
If it should do division the same way for every operation then you must
November 2005 15:37
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] Proposed 3.3.0 changes. Was: 5/2==2
Consider the following SQL:
CREATE TABLE t1(a INTEGER, b REAL);
INSERT INTO t1 VALUES(5,5);
SELECT a/2, b/2 FROM t1;
>From the above SQL, SQLite version 3.2.7 and earlier will ret
> Am I alone in thinking that a division operator that does
> different things depending on the declared datatype of a
> column is an abomination?
Absolutely not.
On Nov 2, 2005, at 9:36 AM, [EMAIL PROTECTED] wrote:
Consider the following SQL:
CREATE TABLE t1(a INTEGER, b REAL);
INSERT INTO t1 VALUES(5,5);
SELECT a/2, b/2 FROM t1;
From the above SQL, SQLite version 3.2.7 and earlier will return
2|2
If my proposed changes for 3.3.0 go in,
Consider the following SQL:
CREATE TABLE t1(a INTEGER, b REAL);
INSERT INTO t1 VALUES(5,5);
SELECT a/2, b/2 FROM t1;
From the above SQL, SQLite version 3.2.7 and earlier will return
2|2
If my proposed changes for 3.3.0 go in, then the result will be:
2.5|2.5
If I understand
[EMAIL PROTECTED] wrote:
Joe Wilson <[EMAIL PROTECTED]> wrote:
I've found a potential problem -
round() is not a good substitute for the old integer truncation.
Consider the previous Sqlite3 behavior:
sqlite> select 15/8;
1
sqlite> select round(15.0/8.0);
2
Can you recommend or
> No, but I would bet somewhere near the 90%+ range are "commercial"
> applications, requiring the management of fixed point bankers
> ("European" or "English") rounding numeric data.
I've been writing commercial applications for about 20 years now,
including 10 years on payroll applications for
Zibetti Paolo <[EMAIL PROTECTED]> wrote:
>
> Insert into foo values(5.34);
> Insert into foo values(3.0);
>
> Table foo will contain two rows that both contain a real-type number, so, to
> read the values back from the DB, I can always use sqlite3_column_double().
> With your proposed change it
On 11/1/2005 at 21:59 [EMAIL PROTECTED] wrote:
>John Stanton <[EMAIL PROTECTED]> wrote:
>>
>> Users love such a number system because it is natural and works like
the
>> Arithmetic they learned in Grade School.
>>
>> I find the idea of dividing two integers stored in binary form and
>>
te-users@sqlite.org
> Subject: Re: [sqlite] Proposed 3.3.0 changes. Was: 5/2==2
>
>
> > Well, since you put it that way. May I go one step farther and
> request
> > that this new Dynamic Type also adhere to "Bankers
> Rounding" commonly
> > implement
Well, since you put it that way. May I go one step farther and
request
that this new Dynamic Type also adhere to "Bankers Rounding" commonly
implemented as BCD in other so equipped databases.
Please, no. I'll handle rounding in my application, I don't need it on
the database. Not all
1/3.
Store that mysql ;-) Or what about PI? Or the square root of 10?
Not all reals can be represented as fractions either. Surd-tastic. Whilst
computers are finite state machines such approximations are the most
reasonable compromise between accuracy and performance. Or should that be
> Well, since you put it that way. May I go one step farther and
request
> that this new Dynamic Type also adhere to "Bankers Rounding" commonly
> implemented as BCD in other so equipped databases.
Please, no. I'll handle rounding in my application, I don't need it on
the database. Not all
Arjen Markus wrote:
Fred Williams wrote:
Well, since you put it that way. May I go one step farther and request
that this new Dynamic Type also adhere to "Bankers Rounding" commonly
implemented as BCD in other so equipped databases.
For years I have spent countless hours testing and
[EMAIL PROTECTED] wrote:
John Stanton <[EMAIL PROTECTED]> wrote:
Users love such a number system because it is natural and works like the
Arithmetic they learned in Grade School.
I find the idea of dividing two integers stored in binary form and
getting a gratuitous conversion to floating
tific mathematicians and the world of users were
99%^ business types. So, spare me further anguish... :-)
Fred
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November 01, 2005 12:55 PM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] Proposed 3.3.0
I find your logic clear and rational, but feel that you do not carry it
through to its logical conclusion. If you are avoiding rigid typing and
fixed size records to finally escape from the Hollerith card mindset
which has afflicted IT for a century, then why embrace fixed size binary
will be required to the existing code to
port it to Sqlite 3.3.x.
Bye
-Messaggio originale-
Da: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Inviato:martedì 1 novembre 2005 15.00
A: sqlite-users@sqlite.org
Oggetto:[sqlite] Proposed 3.3.0 changes. Was: 5/2==2
(1) Floating point
: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Inviato:martedì 1 novembre 2005 15.00
A: sqlite-users@sqlite.org
Oggetto:[sqlite] Proposed 3.3.0 changes. Was: 5/2==2
I am proposing to make the changes outlined below in SQLite
version 3.3.0 and I am wondering if these changes
Fred Williams wrote:
>
> Well, since you put it that way. May I go one step farther and request
> that this new Dynamic Type also adhere to "Bankers Rounding" commonly
> implemented as BCD in other so equipped databases.
>
> For years I have spent countless hours testing and sweating rounding
I can think of a very elegant solution to this whole ordeal, which is
inspired by Perl's way of doing things: Have *two* division
operators which have different behaviour and which look different so
you can tell what will happen where they are used, regardless of
their operand data types.
[EMAIL PROTECTED] wrote:
I admit that it has been 4 decades since I was in grade school,
but back in the 60's we were taught that 5/2 is 2.5. Are they
teaching something different now? Or have I misunderstood the
comment?
Ah, but how does the 5 *feel* about being divided by 2 ? is
John Stanton <[EMAIL PROTECTED]> wrote:
>
> Users love such a number system because it is natural and works like the
> Arithmetic they learned in Grade School.
>
> I find the idea of dividing two integers stored in binary form and
> getting a gratuitous conversion to floating point ugly and
] Proposed 3.3.0 changes. Was: 5/2==2
"Preston Zaugg" <[EMAIL PROTECTED]> wrote:
As was discussed in the original
post this would be NON-STANDARD behavior.
The SQL-99 spec says that integer
math remains an integer.
The change I propose (and have now checked into CVS, btw,
though
The more I think about it, the proposed unified numeric model makes
a lot of sense and should be the default with no pragmas or compile-time
options for the old behavior. The dynamic manifest typing model of Sqlite
practically begs to have uniform mathematical results given the
dynamic nature
Also, regarding the name change suggestions, I disagree.
As people have said, no database product is fully SQL standard
compliant, and SQLite is no different in that regard.
So in the current environment, SQLite's name is *not* misleading,
despite any deviations.
The name is a brand
To answer Richard's question directly:
I do not see the proposed change causing any hardship for me.
I happen to like static typing myself due to its ability to help
prevent bad data from propagating, with explicit variadic data type
for people that don't want to choose a more restrictive
On 11/1/05, René Tegel <[EMAIL PROTECTED]> wrote:
> Jay Sprenkle wrote:
>
> >If you're going to become less compliant perhaps it would be less
> >misleading to remove the "SQL" from the project name. I'm not saying
> >either is a bad idea, just that the name shouldn't be misleading.
> >
> >
> I
I don't see any current integer behavior that cannot be emulated
with the new unified numeric type, but you might have to document
the behavior of mathematical operators under the new system.
Is modulus an integer operation or a floating point operation, for
example? Arguably, it could be
[EMAIL PROTECTED]
Sent: Tuesday, November 01, 2005 10:55 AM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] Proposed 3.3.0 changes. Was: 5/2==2
With the above clarification, I will restate the question:
Suppose SQLite were to merge "integer" and "real" into a
[EMAIL PROTECTED] wrote:
Jay Sprenkle <[EMAIL PROTECTED]> wrote:
On 11/1/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
All of the arguments against my proposed changes are
basically of the form that "this is not what the SQL standard
says". They are theoretical arguments based on
Jay Sprenkle wrote:
If you're going to become less compliant perhaps it would be less
misleading to remove the "SQL" from the project name. I'm not saying
either is a bad idea, just that the name shouldn't be misleading.
I think this is kind of 'purist fetisjism'. Personally I like the
On Tue, Nov 01, 2005 at 01:45:04PM -0600, Jay Sprenkle wrote:
> > > I think it's a bit misleading to call the library "SQL-Lite: if
> > > you're going to redesign and not be like SQL. What do you think
> > > about creating a separate project for a fast light database
> > > engine that's not "SQL
At 1:54 PM -0500 11/1/05, [EMAIL PROTECTED] wrote:
Please let me restate the proposed change: I desire to change
SQLite so that it no longer distinguishes between integer and
real. The two concepts are merged into a unified "numeric"
type.
And because all number values are of the same type,
> > I think it's a bit misleading to call the library "SQL-Lite: if you're
> > going to redesign
> > and not be like SQL. What do you think about creating a separate
> > project for a fast
> > light database engine that's not "SQL Like"?
>
> SQLite is very much SQL. It only deviates from the
- Original Message -
From: "Jay Sprenkle" <[EMAIL PROTECTED]>
To: <sqlite-users@sqlite.org>
Sent: Tuesday, November 01, 2005 2:08 PM
Subject: Re: [sqlite] Proposed 3.3.0 changes. Was: 5/2==2
> I think it's a bit misleading to call the library "SQL-Lite:
Jay Sprenkle said:
> On 11/1/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>> All of the arguments against my proposed changes are
>> basically of the form that "this is not what the SQL standard
>> says". They are theoretical arguments based on a world-view
>> that holds that strong-typing
Jay Sprenkle <[EMAIL PROTECTED]> wrote:
> On 11/1/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > All of the arguments against my proposed changes are
> > basically of the form that "this is not what the SQL standard
> > says". They are theoretical arguments based on a world-view
> > that
y, November 01, 2005 12:55 PM
> To: sqlite-users@sqlite.org
> Subject: Re: [sqlite] Proposed 3.3.0 changes. Was: 5/2==2
>
...
> Please let me restate the proposed change: I desire to change
> SQLite so that it no longer distinguishes between integer and
> real. The two concepts ar
On 11/1/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> All of the arguments against my proposed changes are
> basically of the form that "this is not what the SQL standard
> says". They are theoretical arguments based on a world-view
> that holds that strong-typing is good and that it is the
There is an ongoing debate on this subject at Lambda the Ultimate. One
approach that is sound is to introduce a new static type, called
DYNAMIC, that permits any value. Summarizing and seconding Dennis
Cote's suggestion, perhaps columns that have no type declared, or that
are declared DYNAMIC,
All of the arguments against my proposed changes are
basically of the form that "this is not what the SQL standard
says". They are theoretical arguments based on a world-view
that holds that strong-typing is good and that it is the duty
of database systems to enforce types.
I do not hold to that
Dennis Cote wrote:
The second issue is demonstrated by the last last three statements.
CREATE TABLE t (a REAL, b REAL);
INSERT INTO t VALUES (5, 2);
SELECT a / b FROM t;
Here he has explicitly declared the columns a and b to be of type
real. He then stores integer literal values into
ld you
do? As modern PDA's now seem to have a minimum of 8M or so. And these
kind of enhancement requests just keep coming.
Fred
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, November 01, 2005 10:53 AM
> To: sqlite-users@sqlite.org
&g
In Delphi we have the Type: "Variant," which is pretty much "Type-less"
for OOP purposes.
> -Original Message-
> From: Doug Currie [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, November 01, 2005 11:25 AM
> To: sqlite-users@sqlite.org
> Subject: Re: [sqlit
Tuesday, November 1, 2005, 11:53:11 AM, [EMAIL PROTECTED] wrote:
> Static typing in SQL is designed not to help the users of SQL
> databases, but rather to help the implementors of SQL database
> engines.
There are uses for static typing. Types in the SQL context can be used
as a kind of
Joe Wilson <[EMAIL PROTECTED]> wrote:
> I've found a potential problem -
> round() is not a good substitute for the old integer truncation.
>
> Consider the previous Sqlite3 behavior:
>
> sqlite> select 15/8;
> 1
> sqlite> select round(15.0/8.0);
> 2
>
> Can you recommend or provide a
"Fred Williams" <[EMAIL PROTECTED]> wrote:
> Ah the sticky wicket that is "Type less" :-) We now have issues
> evolving as a direct result of that feature in our cute little database.
> We now seem to have by backing into it: Really Restricted Integer, Real,
> DateTime (sort of), and Text. BLOB
Preston Zaugg wrote:
I would NOT be in favor of this change. As was discussed in the
original post this would be NON-STANDARD behavior. The SQL-99 spec
says that integer math remains an integer.
The only time I would like an integer to return a "real" result is if
that integer is stored
I've found a potential problem -
round() is not a good substitute for the old integer truncation.
Consider the previous Sqlite3 behavior:
sqlite> select 15/8;
1
sqlite> select round(15.0/8.0);
2
Can you recommend or provide a new function that performs correct integer
trunction?
---
On 11/1/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> I am proposing to make the changes outlined below in SQLite
> version 3.3.0 and I am wondering if these changes will cause
> any severe hardship.
Stay with the SQL standard, if that's not clear follow what other languages do..
int
Is it time to officially declare/fully support some Types and clear the
air?
Fred
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, November 01, 2005 9:43 AM
> To: sqlite-users@sqlite.org
> Subject: Re: [sqlite] Proposed 3.3.0 changes. Was: 5/
Joe Wilson <[EMAIL PROTECTED]> wrote:
>
> How do intend to treat 5/2 if passed to an Sqlite function expecting
> an integer argument?
Exactly the same thing that happens now if you pass 2.5
into that same function: it truncates the value to an
integer 2.
--
D. Richard Hipp <[EMAIL PROTECTED]>
"Preston Zaugg" <[EMAIL PROTECTED]> wrote:
> As was discussed in the original
> post this would be NON-STANDARD behavior.
> The SQL-99 spec says that integer
> math remains an integer.
>
The change I propose (and have now checked into CVS, btw,
though I might still back it out) does not
e Wilson [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, November 01, 2005 9:10 AM
> To: sqlite-users@sqlite.org
> Subject: Re: [sqlite] Proposed 3.3.0 changes. Was: 5/2==2
>
>
> Although all my Sqlite3 databases depend on integer division
> truncation
> and would break with your p
quot; if stored
in a "real" column, otherwise it should act as it currently does.
Thanks for asking for opinions before making the change
Preston
From: [EMAIL PROTECTED]
Reply-To: sqlite-users@sqlite.org
To: sqlite-users@sqlite.org
Subject: [sqlite] Proposed 3.3.0 changes. Was: 5/2==2
Dat
Although all my Sqlite3 databases depend on integer division truncation
and would break with your proposed change I agree that 5/2 should equal
2.5 in order to be more consistant with other databases. I can migrate
my databases to use round(). But might it be possible to create a
backwards
I am proposing to make the changes outlined below in SQLite
version 3.3.0 and I am wondering if these changes will cause
any severe hardship.
Two changes working together:
(1) Floating point values are *always* converted into
integers if it is possible to do so without loss
of
82 matches
Mail list logo
