OTECTED]
Sent: Wed 14-Dec-05 7:35 PM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] Problem with floating point fields, and a feature request
Dave Dyer wrote:
select * from test where f=13.06; -- returns no data
Pardon me for throwing a bomb, but no good programmer
would ever use = to
A simple "fuzzy" tolerance will not solve the problem, only mask
it for the most common cases. A single floating point addition
of two numbers can result in ZERO bits of precision.
Cariotoglou Mike wrote:
>
> I see again that you all miss the point. I DO know how to handle floating
> point. My point is :
>
...
>
> since a solution to this issue is fairly simple, and the applicable audience
> is large, why not provide one?
> the fact that MSSQL will not be able to do the
as
stopped drh before, has it.
From: John Stanton [mailto:[EMAIL PROTECTED]
Sent: Wed 14-Dec-05 7:35 PM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] Problem with floating point fields, and a feature request
Dave Dyer wrote:
>>>select * from
Hello Dave,
Perhaps I'd have said it's "poor practice" to compare floating point
numbers that way. I think you're right but, the wording changes make an
attack into valid criticism.
C
Wednesday, December 14, 2005, 11:58:11 AM, you wrote:
>>>
>>>select * from test where f=13.06; -- returns no d
Dave Dyer wrote:
select * from test where f=13.06; -- returns no data
Pardon me for throwing a bomb, but no good programmer
would ever use = to compare floating point numbers.
Choose a more appropriate representation for your data.
It is not a bomb, just something novice programmers have to
>>
>>select * from test where f=13.06; -- returns no data
Pardon me for throwing a bomb, but no good programmer
would ever use = to compare floating point numbers.
Choose a more appropriate representation for your data.
On 12/14/05, Cariotoglou Mike <[EMAIL PROTECTED]> wrote:
> I now have a concrete example, which actually happened in an
> installation, and helps to demonstrate the severity of the issue:
>
> try this code:
>
> create table test(f double);
> insert into test values(13.04);
> update test set f=f+0.0
create table test(f double);
insert into test values(13.04);
update test set f=f+0.02;
select * from test where f=13.06; -- returns no data
Using MS SQL Server 2000, substituting the "float" type (with a range
of -1.79E+308 through 1.79E+308) for your double, I get the same
results, i.e. no da
as you may remember, some time ago I raised an issue with floating point
accuracy, and how this may affect sqlite.
I now have a concrete example, which actually happened in an
installation, and helps to demonstrate the severity of the issue:
try this code:
create table test(f double);
insert int
Cariotoglou Mike wrote:
>
> as you may remember, some time ago I raised an issue with floating point
> accuracy, and how this may affect sqlite.
>
> I now have a concrete example, which actually happened in an
> installation, and helps to demonstrate the severity of the issue:
>
> try this code:
--- Cariotoglou Mike <[EMAIL PROTECTED]> wrote:
> collating sequences do not apply to floating point comparisons, do they?
Hmmm, excellent point. Guess I didn't think too hard about that
one.
But the other point is the real show-stopper, how should the software deal
with the circumstances wher
On 9/20/05, Cariotoglou Mike <[EMAIL PROTECTED]> wrote:
>
> nothing, when you hand-code. everything, when the code is
> auto-generated, which very frequently it is
Automatically generated bad code is still bad code.
If it's generating floating point comparisons now it's bad code.
It only works m
also, it kills the usage of indexes, whereas what I propose would not.
> -Original Message-
> From: Jay Sprenkle [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, September 20, 2005 5:04 PM
> To: sqlite-users@sqlite.org
> Subject: Re: [sqlite] Problem with floating point f
e] Problem with floating point fields, and
> a feature request
>
> On 9/20/05, Cariotoglou Mike <[EMAIL PROTECTED]> wrote:
> >
> > There is an issue with floating point fields, which exists in every
> > database I have dealt with, and of course exists in sqlite as well,
collating sequences do not apply to floating point comparisons, do they
?
> -Original Message-
> From: Dan Kennedy [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, September 20, 2005 5:12 PM
> To: sqlite-users@sqlite.org
> Subject: Re: [sqlite] Problem with floating point f
> two floats A and B should be compared with this algorithm :
>
> diff=A-B
> if (diff>tolerance) then A>B
> else if (diff<-tolerance) then A else A = B
You could define a new collation sequence to do all that. However, it's
difficult to say what will happen when you have three numbers A, B and
On 9/20/05, Cariotoglou Mike <[EMAIL PROTECTED]> wrote:
>
> There is an issue with floating point fields, which exists in every
> database I have dealt with, and of course exists in sqlite as well, all
> versions.
> Essentially, the issue is this:
>
> "When are two floating point values considered
There is an issue with floating point fields, which exists in every
database I have dealt with, and of course exists in sqlite as well, all
versions.
Essentially, the issue is this:
"When are two floating point values considered equal ?"
Why is this an issue ?
Floating point values are some time
19 matches
Mail list logo