Subject | Re: Bug: "-0" <> "0" in FB indexes !!! |
---|---|
Author | bjorgeitteno |
Post date | 2004-03-26T11:33:42Z |
--- In firebird-support@yahoogroups.com, "Steffen Heil" <lists@s...>
wrote:
select (0.0*-1.0)*10e307 val from rdb$database
...you'll get a result of 0. If the "approximation" of (0.0*-1.0)
contained any digits <> 0 at all, it would be present. I believe,
with the binary formats of floats, '0.0' is an exact value. Of course
it
is with the currently used formats, because a '0.0' is a variable
filled with 0's, and a '-0.0' is the same except for the sign bit set
to 1.
But if one *wanted* two zero types, it should be concistent. One
should not treat the values differently when dealing with indexes and
with normal field value retrieval.
I believe one doesn't want a database engine to distinguish between
positive and negative zero. If one was to deal with complex maths,
one might want to, of course.
A statement like:
select * from tbl where float_field = 0.0
correctly (or *not*, if you want to distinguish, of course) returns
the rows containing "float_field = 0" or "float_field = -0". *If* a
usable index is not present.
Assuming that the value stored (-0.0) is the correct outcome of the
computation:
-1 * 0
..then the behaviour of FB shown in the select statement above is not
correct provided you want the two values to be distinct.
No matter what the conclusion to this is, one thing needs being fixed:
- The values 0.0 and -0.0 should be either be equal or different
*conistently*
- And, If distinction is implemented: The value -0.0 should sort
between 0 and -1, not as today's 'negative infinity'. Client-side
components must also be able to display '-0'.
I'm really curious about the internals of FB - why -0.0 is evaluated
to be the "most negative number"....
Anyone shed a light on this ?
wrote:
> You are writing 0 and -0, not 0.0 and -0.0, but I assume you reallymean
> floating point numbers.if you run this:
> So what do floating point numbers mean? They are approximations.
>
> +0.0 means somewhere near 0.0, maybe a litte more.
> -0.0 means somewhere near 0.0, maybe a litte less.
select (0.0*-1.0)*10e307 val from rdb$database
...you'll get a result of 0. If the "approximation" of (0.0*-1.0)
contained any digits <> 0 at all, it would be present. I believe,
with the binary formats of floats, '0.0' is an exact value. Of course
it
is with the currently used formats, because a '0.0' is a variable
filled with 0's, and a '-0.0' is the same except for the sign bit set
to 1.
But if one *wanted* two zero types, it should be concistent. One
should not treat the values differently when dealing with indexes and
with normal field value retrieval.
I believe one doesn't want a database engine to distinguish between
positive and negative zero. If one was to deal with complex maths,
one might want to, of course.
A statement like:
select * from tbl where float_field = 0.0
correctly (or *not*, if you want to distinguish, of course) returns
the rows containing "float_field = 0" or "float_field = -0". *If* a
usable index is not present.
> [In fact, 0.0 is here used to explain, it does NOT exist at all.Floating
> point systems only know about +0.0 and -0.0]...which is about the only practical use for this number...
>
> Another point to see, that they are NOT equad:
>
> +1.0 / +0.0 = +infinity
> +1.0 / -0.0 = -infinity
Assuming that the value stored (-0.0) is the correct outcome of the
computation:
-1 * 0
..then the behaviour of FB shown in the select statement above is not
correct provided you want the two values to be distinct.
No matter what the conclusion to this is, one thing needs being fixed:
- The values 0.0 and -0.0 should be either be equal or different
*conistently*
- And, If distinction is implemented: The value -0.0 should sort
between 0 and -1, not as today's 'negative infinity'. Client-side
components must also be able to display '-0'.
I'm really curious about the internals of FB - why -0.0 is evaluated
to be the "most negative number"....
Anyone shed a light on this ?