I've a TDbGrid linked to a TDataSet wich contains a few TFloatField columns.
When I enter a decimal value in a FloatField column, I get strange values:
100.05 becomes 100.050003051758
500.05 becomes 500.049987792969
I'm using a MySQL database and looking at the value it seems OK. I've Delphi
6 Enterprise French with all patches.
Also I'm using a PIV core2duo quite new (1 month), and I can't believe it
can be a floating problem with the microprocessor.
I can put a ###.00 format in DisplayFormat of the field, but this value will
be used later for calculations and I'm scared it will make errors in
results.
Can someone tell me what's wrong with this ?
Thanks for help.
Bob
Or maybe a better example is here, in the Floating-Point Complications
section
http://support.microsoft.com/kb/42980
Nothing wrong here, that's just the innability of floating point variables
Well Bob, welcome to the real world, the world of floating
binary point variables like double, single, and extended.
Do you expect to be able to store 1/3 exactly in a *decimal*
fraction variable? For the same reason you cannot store
1/10 in a *binary* fraction variable. If you want t see the
*exact* value of your single, double, or extended variables,
you need to use one of the functions in ExactFloatToStr_JH0
which is available free from CodeCentral at
http://cc.codegear.com/Item.aspx?id=19421
Rgds, JohnH
with floating point it is only a reasonably close to the decimal value
as
Just as 1/3 can only be repersented as 0.333333333 for as many digits as
you want -- - it will always be a bit off. the same with floating.
Just have more than enough resolution in the floating point type -
single, double or extended formats.
You will notice that single is about 8 digits of resolution
and to display a floating point number beyond that number of digits is
simply asking for errors in the number - - - displayed as decimal.
You are displaying a floating point single with about 8 digits of
resolution at 15 digits - -
What do you expect to happen. - change the number to Double and try it
again and see what happens.
Jim P.
Thanks anyway.
Bob
Bob
> strange. Dave pointed me on some links but after reading they seems to say
> that the problem occur when calculating with floating numbers but since I
> don't do any calculation, I was thinking as a bug.
>
They probably weren't the best links and may have just confused the issue -
I was trying to find some links while at work, so didn't have a lot of time
to read through the info first. However, as others have stated, this is
really down to the storage accuracy and how many decimal non integral
numbers can be represented in a binary format only to an approximation.
Even though you type is 100.005 at the terminal, and the computer displays
100.005 when you enter this (no conversion to storage format yet, just
display routines), as soon as the program attempts to store that value in a
floating point variable, it will lose some precision and the nearest
representation will be stored instead, which in this case is
100.0050003051758. When you later retrieve that value for display, the
program will retrieve the imprecise value and display that, assuming that it
is the correct value.
If you really need absolute accuracy, then floating point numbers aren't the
best choice. Depending on your application, some kind of fixed point
storage would be more appropriate.
Dave White
Bob
the conversion from a string to float is a calculation. - - the string
is a text string - - the float is a binary repersentation of the string
value - - binary is base 2, 4, 8, 16 etc never does match perfectly to
decimal values - - -
again the representation is as close as the resolution of the of the
precision of the floating point number - - -
a single is typically 8 digits +/- depending and for 8 digits it is
accurate - - you are trying to display more than the precision of the
number. Try a double and see what happens. More bits - - closer to
being accurate to 15 or so digits.
try displaying the number formated as xx0.0000 and see what you get - -
the right number correct.
Jim P.
JohnH wrote:
> > Do you expect to be able to store 1/3 exactly in a *decimal*
> > fraction variable? For the same reason you cannot store
> > 1/10 in a *binary* fraction variable. If you want t see the
> > *exact* value of your single, double, or extended variables,
> > you need to use one of the functions in ExactFloatToStr_JH0
> > which is available free from CodeCentral at
> > http://cc.codegear.com/Item.aspx?id=19421
"Bob Bedford" <b...@bedford.com> wrote
> I didn't expect to store 1/3 exactly in a decimal, but I just
> found [it] amazing to have a strange number for input entry
> values.
May I ask how long have you been doing programming?
If you want the ability to store general decimal fractions
exactly in the future you should consider adding your vote
to the QualityCentral report
http://qc.borland.com/wc/qcmain.aspx?d=28022
titled
"Add Fixed and Floating Decimal Point Numbers to Delphi"
If you want to struggle with the ubiquitous floating binary point
variables and control the rounding yourself, then you need my
decimal rounding package DecimalRounding (JH1) which is
available from
http://cc.codegear.com/item.aspx?id=21909
Regards, JohnH
Thanks Jim, is what I wanted to understand.
Best regards.
> If you want the ability to store general decimal fractions
> exactly in the future you should consider adding your vote
> to the QualityCentral report
> http://qc.borland.com/wc/qcmain.aspx?d=28022
> titled
> "Add Fixed and Floating Decimal Point Numbers to Delphi"
If you readed the real problem here you probably pointed out my problem:
entering a value by hand in a field then storing it in MySQL database
sometimes gives strange results. Others have pointed out and answered
without insulting me.
I wanted to understand why this appens and how this is done internally but I
didn't expect to be insulted about my skills on programming.
The skills of every programmers comes from their experience. In my case I
never worked with floats until now.
Your skills seems very good, you probably have many years experience or you
are a very talented programmer, but I prefeer to be a bad programmer than
have your lack of understanding about people not having your same knowledge.
You also probably pointed out that my mother tongue isn't english, so accept
my apologies for the terms I used here, but you got the general idea of what
I wanted to tell you.
Bob
Best Regards.
"Bob Bedford" <b...@bedford.com> wrote
> A few years, but never with floating numbers....
That is exactly what I wanted to know. You are not
alone. Many successful programmers have gone
for years w/o learning about how floating binary
point numbers work. Some otherwise successful
programmers who use floating binary point numbers
have even gone a few years without knowing that
such numbers only give you approximations to what
they were thinking that the numbers really contained.
That is why I wrote and posted my ExactFloatToString
routines which can be found in ExactFloatToStr_JH0
which is available free from CodeCentral at
http://cc.codegear.com/Item.aspx?id=19421
(You did not mention that you tried it.)
I suggest that any of the exact-float-to-string these
routines will surprise you about the numbers that you
are using and enable you to diagnose the problem
of this thread and many others.
I suggest also that if you would like the ability to store
and compute with general decimal fraction numbers
*exactly as you see them*, then, if you have not already
done it, I suggest that you should consider adding your
vote to the QualityCentral report
http://qc.borland.com/wc/qcmain.aspx?d=28022
titled
"Add Fixed and Floating Decimal Point Numbers to Delphi"
In the meantime, I will again mention, that if you want
to struggle with the ubiquitous floating binary point
variables and control the rounding yourself, then you
need to look at my decimal rounding package
DecimalRounding (JH1) which is also available from
CodeCentral at
http://cc.codegear.com/item.aspx?id=21909
It is designed to work with the inaccuracies of these
floating *binary* point numbers when representing
*decimal* fraction numbers and do a good job of
handling rounding of the borderline cases.
Regards, JohnH