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
t has
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
>>
>>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
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
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
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
--- 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
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
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 floati
sqlite] 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 wel
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 floati
> 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
18 matches
Mail list logo
