Computers rational and irrational numbers

[SixNein]

SixNein -- I really think you are so focused on the point you want to convey that you are overstating yourself (e.g. you repeatedly creep into assertions about "all number systems") and , and you are not recognizing the variations that others are talking about (e.g. matrix seems to point out that any particular rational arithmetic calculation can be done with finite precision in radix form for many bases)

I think we are just on different pages, and it didn't help for the discussion to be broken into two posts. For example, I was the first to mention that number libraries can be used. The discussion began with the issue of making exact floating point comparisons in programming languages for rational numbers. A programmer might do a calculation like 5 * (1/5) and try to do an exact comparison of 1 and the result. When the test fails, the programmer is surprised.

My argument here is that it doesn't matter what number system is being used for the calculation because programmers will always get into trouble when doing floating point comparisons. The mathematical reason is that only a subset of rational numbers can be stated exactly as reals for any particular base, and the rest will be approximated. So the only way to get around this issue is to work with rational numbers as fractions and avoid real conversions altogether.

There is nothing special about binary that causes this issue of floating point comparisons to occur. The only difference between using binary and decimal is the subsets one would get that can be stated exactly as reals, and this difference is due to the arithmetic being performed to come up with the real.

 

[rcgldr]

My argument here is that it doesn't matter what number system is being used for the calculation because programmers will always get into trouble when doing floating point comparisons.

Depends on the language implementation of comparasons. For languages with a "relative fuzz" factor (like APL), this normally isn't an issue. The comparsons using a fuzz factor in floating point use the following formulas:

A > B => A > (B - |B * fuzz|)
A < B => A < (B + |B * fuzz|)
A == B => A > (B - |B * fuzz|) && A < (B + |B * fuzz|)

The issue here is that it's possible for (A > B && A == B) || (A < B && A == B) to be true.

In languages that don't support "relative fuzz" factor, the programmer normally compensates with his/her own fuzz factor something like for(A = 0.0; A < 4.99; A += .1) // loop 50 times ... .

I don't understand why this got so much attention as I doubt there are many programmers that ever ran into this problem more than once if at all, since this and other issues are typically covered during school or early training of a programmer.

 

[Hurkyl]

A programmer might do a calculation like 5 * (1/5) and try to do an exact comparison of 1 and the result. When the test fails, the programmer is surprised.

Surprise is really just an artifact of inexperience. They put in a debug statement, see the result is zero, are properly embarrassed for a few moments.

And similarly it's general procedure never to compare floating point numbers for equality and instead check if the absolute difference is sufficiently small. (unless you really know what you're doing)

My argument here is that it doesn't matter what number system is being used for the calculation

Again, you are in the habit of overstating yourself. You know very well that you are restricting yourself solely to radix representations of finite precision and there are other number systems that don't have the issues you're bringing up.

because programmers will always get into trouble when doing floating point comparisons.

No, not always. For example, they will never get into trouble when they work with dyadic fractions with sufficiently few significant bits required.

In fact, on some machines, people use floating-point calculations so that they can do exact integer computations more efficiently. (e.g. because a CPU has a really good floating point unit as compared to its integer unit, or maybe because doing so let's them use both the integer and floating point units simultaneously)

So the only way to get around this issue is to work with rational numbers as fractions and avoid real conversions altogether.

Actually, this is not the only way to get around the issue.

One particular example is that there are a exact numerical algorithms that work by using approximate but fast floating-point arithmetic to obtain an approximate solution, and then use some means (e.g. continued fractions, lattice reduction) to convert into a rational number. Upper bounds on the error of calculation and the size of the denominator can be used to guarantee exactly correct results.

Such algorithms, I believe, are very important in computational number theory.

 

[Jocko Homo]

Again, you are in the habit of overstating yourself. You know very well that you are restricting yourself solely to radix representations of finite precision and there are other number systems that don't have the issues you're bringing up.

Is the whole problem in this thread that people are talking past each other?

In particular, when someone refers to floating point arithmetic, they're talking very specifically about a system that use radix representations of finite precision. It looks like other people are using the term "floating point" to mean any representation of the real numbers...