Le me add a comment here or two:
Fractions are presented in the form 1234/5678, which is an incomplete division form. If the division is performed, the value may appear to be 0.2173300458, if your calculator can display that many places. A calculator with only an 8-digit display will only show 0.2173300. Which of these is the correct answer? How about 1/3, which is shown as 0.3333333333 on my calculator, buy may only show as 0.3333333 on yours. Do they agree? Are they the same? Are they truely accurate?
We have three considerations: Precision, accuracy, and range. How precisely a value can be represented, how accurate a value can be represented, and the range over which values can be represented.
As you probably learned in school, positive numbers can go towards infinity, negative numbers can go towards infinity, and fractions can go towards infinity, either getting bigger, or ever smaller as they approach zero. But infinity is not a place you can ever get to, it is a concept of there always being something more, something still reachable, without end.
So we cannot represent infinity when we build machines, because they are finite (have limits) by nature. The is always going to be a maximum large number or maximum small number involved, so while we can easily represent zero, there is no infinity, large or small, that we can represent or obtain using a machine.
In fact, we have no way at all of representing the concept of infinity in and of itself, within a computer. There is no "without end", unless you consider the infinite loop, which is a ceaseless process (but we can always stop it).
So we cannot have infinite precision, nor infinite accuracy, nor infinite range, when dealing with numbers, expressions, or results. We can only go so far. And because of this, we round off values. Either we do it, or the machine does it for us. And when we carry on computations involving rounded-off values, we get round-off errors. And the more complex the computations, the more likely that the round-off errors will grow in size and distort our results. The computer, in comparing two values, is looking for an exact match to the limits of its ability to accurately represent both values, or determine that one value is larger than the other. Because of round-off errors, the values represented may be such that the wrong value may appear to be larger, or they may appear to be equal when they truely are not, or they may appear to be slightly different when they should be exactly the same.
So, in general, you are not concerned with accuracy and round-off errors until you ask the computer to compare values for you, and then you run into the problem of round-off errors causing you grief. Well, the fact is, round-off errors give you an added half-bit of accuracy, where truncated values lack that feature. But truncated values also lead to truncation errors, which are at least as bad as round-off errors, and often worse.
So what is the answer? Round-off errors most commonly occur when you divide, so do all your multiplies first if you can. Instead of testing for exact matches, you may have to use the >= and <= test to see if a value is within an acceptable range. such as:
If a#>=1.333 And a#<=1.334 Then
Or you could try...
IF a#=Float(1/3) Then
Some programmers do not like that second form, because it means an extra divide step each time it is executed. But it means you are checking a# to the limits of the accuracy of the representation possible, and besides, a smart compiler could recognize the use of constants and here and store the results of 1/333 as an internal representation of 0.333333333333... to as many places as it can.
Still, round-off and truncation errors can haunt you, so just keep it in mind that you may have to try a variety of methods to narrow the error down to something you can live with.