Paranoic about real number imprecisions

  • Thread starter Thread starter Pavils Jurjans
  • Start date Start date
P

Pavils Jurjans

Hallo,

It is know issue that due to the fact that computer has to store the real
numbers in limited set of bytes, thus causing a minor imprecision from the
decimal value that likely was stored. I don't know, how dotnet framework
stored doubles, but it's certain, that if I store, say, 1.234567 in some
real variable, it is stored in memory like something close to
1.2345670000000000000003454786544 or
1.234566999999999999999999999999999924354324.

Due to this problem it may sometimes cause some unexpected results when
comparing the real numbers in "if" statement.

Some programming languages have built-in protection, that compares only
limited number of digits (less than declared capability of the type), when
asked to compare two real numbers, thus the garbage in the lesser decimal
fields goes unnoticed. I have been using an "ApproximatelyEqual" method, for
comparing two real numbers and providing precision:

input: A, B, precision
output: (abs(A-B) <= 10^(-precision))

Example:
A = 1.00000000000001
B = 1.00000000000007
precision = 13
abs(A-B) = 0.00000000000006
10^(-precision) = 0.0000000000001
abs(A-B) <= 10^(-precision) = true

precision = 14
10^(-precision) = 0.00000000000001
abs(A-B) <= 10^(-precision) = false

For a project I am working on, where there are done multiple operations with
real numbers, I wanted to be sure, where there are some traps I may fall in.
Is it safe to compare the real numbers without custom "ApproximatelyEqual"
method?

Thanks,

Pavils
 
For real good precicion use the decimal type. Is is slower than double and
uses more memory but it is much more suited for precise calculations.
 
Why you don't use double?

Using double type will not save from this problem.

Pavils
 
Once I had the same problem, I have to calculate some value and compare
them,
with float I have always precision errors, with double never.
 
You can not count on double, as it has the same problem that a float
has.

You should use the Decimal type. It will store numbers with a large
amount of decimal places accurately.

Hope this helps.
 
no, but the decimal type will, as Nicholas points out.

Any reason this won't work? I don't know what calculations you are using...
decimal isn't appropriate for every binary operation, but it is very good in
this situation because it doesn't store the number in a "true" binary
format... it stores the decimal digits themselves.

--- Nick Malik
 
Zürcher See said:
Once I had the same problem, I have to calculate some value and compare
them, with float I have always precision errors, with double never.
Click to expand...

You've been lucky then.

Double has more precision than float, but it's still unable to
represent variable numbers (eg 0.1) exactly.
 
Nick Malik said:
no, but the decimal type will, as Nicholas points out.
Click to expand...

Well, that depends.
Any reason this won't work? I don't know what calculations you are
using... decimal isn't appropriate for every binary operation, but it
is very good in this situation because it doesn't store the number in
a "true" binary format... it stores the decimal digits themselves.
Click to expand...

Indeed. It is able to exactly represent every decimal number. Of
course, that doesn't help if you're dealing with numbers which can't be
exactly represented in decimal - such as 1/3.

If you're dealing with numbers which can always be exactly represented
in decimal even after all the operations you're interested in,
decimal's great - but it's just another floating point type with all
the associated problems really.
 
Jon Skeet said:
Well, that depends.
Click to expand...

True. My "snappy reply" was overly broad and I could have qualified it
better. Unfortunately, the OP hasn't provided enough detail about his or
her calculations to make it clear if this particular numeric type would be
any more appropriate, or why they need to compare against specific real
numbered values.

We are left to guess.
Indeed. It is able to exactly represent every decimal number. Of
course, that doesn't help if you're dealing with numbers which can't be
exactly represented in decimal - such as 1/3.

If you're dealing with numbers which can always be exactly represented
in decimal even after all the operations you're interested in,
decimal's great - but it's just another floating point type with all
the associated problems really.
Click to expand...

No argument here. That's why I posed the follow-up question. There are
specific mitigations for working around issues where the rational number can
be managed as a numerator and denominator until the last possible moment,
which can, depending on the calculation, maintain a bit more of the
precision. That isn't common but it does sometimes work. Other mitigations
rest with use of factors, matrix operations, formulaic representations, etc.
Once again, their applicability depends on information that the OP has not
provided.

When, or if, the OP decides to weigh in with more information, I'll be happy
to engage in a (hopefully) fruitful discussion of the uses of binary math to
solve the problem. Until then, we are, as they say in my home town of
Knoxville, "spittin' in the wind."

--- Nick
 
Nick Malik said:
True. My "snappy reply" was overly broad and I could have qualified it
better. Unfortunately, the OP hasn't provided enough detail about his or
her calculations to make it clear if this particular numeric type would be
any more appropriate, or why they need to compare against specific real
numbered values.

We are left to guess.
Click to expand...

Indeed :(

I guess my reason for replying was that there is a misconception around
that somehow decimals are "precise" whereas float/double aren't. Of
course, pinning down exactly what people mean by "precise" is a tricky
business - decimal/float/double are all precise, in that they exactly
represent numbers. They just don't exactly represent *all* numbers,
including the true results of many operations working with the precise
original numbers...
No argument here. That's why I posed the follow-up question. There are
specific mitigations for working around issues where the rational number can
be managed as a numerator and denominator until the last possible moment,
which can, depending on the calculation, maintain a bit more of the
precision. That isn't common but it does sometimes work.
Click to expand...

Yup. I seem to remember that it used to be a big performance win too,
in the right circumstances - these days FP units are probably fast
enough to counter a lot of the performance benefits of sticking with
integers.
Other mitigations
rest with use of factors, matrix operations, formulaic representations, etc.
Once again, their applicability depends on information that the OP has not
provided.

When, or if, the OP decides to weigh in with more information, I'll be happy
to engage in a (hopefully) fruitful discussion of the uses of binary math to
solve the problem. Until then, we are, as they say in my home town of
Knoxville, "spittin' in the wind."
Click to expand...

:)
 
Back
Top