> Er, no,
>
> 12.3399 < float_var < 12.3400
>
> works fine.
>
> It is the = operation that doesn't. Remember that floating
> point numbers
I don't understand why you think inexact numbers won't compare, the
originators comparison works for '12.3' works with several other types
[ database mysql query ]
Sinisa Milivojevic wrote:
>On Fri, 01 Feb 2002 15:21:07 -0800
>Steve Edberg <[EMAIL PROTECTED]> wrote:
>
>>...perhaps a NEAR function could be added; as a config file or
>>compile-time option, you could define an accuracy range. Say,
>> ./config --with-epsilon=0.0001
>
On Fri, 01 Feb 2002 15:21:07 -0800
Steve Edberg <[EMAIL PROTECTED]> wrote:
> ...perhaps a NEAR function could be added; as a config file or
> compile-time option, you could define an accuracy range. Say,
>
> ./config --with-epsilon=0.0001
>
> (if memory of my numerical analysis classes
...perhaps a NEAR function could be added; as a config file or compile-time
option, you could define an accuracy range. Say,
./config --with-epsilon=0.0001
(if memory of my numerical analysis classes serves, the 'fudge factor' was
conventionally symbolized by epsilon; I suppose you co
On Friday 01 February 2002 14:19, Jim Dickenson wrote:
> Am I to assume that based on your response that one should never use a
> float field type if you ever want to select the data?
Er, no,
12.3399 < float_var < 12.3400
works fine.
It is the = operation that doesn't. Remember that
[ database query mysql ]
Jim Dickenson wrote:
> Am I to assume that based on your response that one should never use a float
> field type if you ever want to select the data?
No, that wasn't quite what he said.
You can certainly select on a float field, as long as you perform a
meaningful o
Yes, but you need to use the decimal (fixed-point) type, not the floating
point type. Any program that's directly comparing FP numbers for exact
matches is simply wrong, and certainly won't be portable, even if it works
in one particular environment. Fixed-point numbers CAN be compared for
exac
Am I to assume that based on your response that one should never use a float
field type if you ever want to select the data?
This causes a big problem for the way MyODBC 3.51 has been implemented. I
was actually debugging a problem I had in MyODBC when I ran across this. The
way MyODBC works is t
At 13:33 -0800 2/1/02, Jim Dickenson wrote:
>I am running mysql Ver 11.15 Distrib 3.23.47, for pc-linux-gnu (i686)
>installed from a binary RPM file. This is using RedHat Linux 7.2.
>
>I have a table described as:
>mysql> describe junk;
>++---+--+-+-+---+
>
A floating point number can never be equal to 12.3.
It can be close, and with rounding display as 12.3, but it
won't actually be equal to 12.3.
Use a decimal type instead.
Jim Dickenson wrote:
>I am running mysql Ver 11.15 Distrib 3.23.47, for pc-linux-gnu (i686)
>installed from a binary RPM f
I am running mysql Ver 11.15 Distrib 3.23.47, for pc-linux-gnu (i686)
installed from a binary RPM file. This is using RedHat Linux 7.2.
I have a table described as:
mysql> describe junk;
++---+--+-+-+---+
| Field | Type | Null | Key | Default | E
11 matches
Mail list logo
