<h1>Tech Notes</h1><h2>Floating Point Math. Why doesn't .1 = .1?</h2><p>Older versions of FutureBASIC and ZBasic used a type of math called Binary Coded Decimal (BCD). This type of math was powerful and exact, but very slow. BCD math was really base 10 arithmetic. If we wanted to represent a number that number was represented exactly.</p>
<p>Modern math packages are “base 2” and are often referred to as binary math. Let’s start with a simple example that shows the difference between the two math packages.</p>
<pre>
DIM myFloat1#,myFloat2#
myFloat1# = .1
myFloat2# = FRAC(VAL("460.1"))
PRINT myFloat1#,myFloat2#
LONG IF myFloat1# = myFloat2#
BEEP : REM Why doesn't this beep???
END IF
</pre>
<p>This isn’t rocket science. You can easily see that <span class="pre">myFloat1#</span> and <span class="pre">myFloat2#</span> are identical. It used to work OK in older version of FB (using the BCD math package). Yet there is no beep when the two are compared in FB. So what’s up with this?</p>
<p>The PPC math package used by FutureBASIC^3 does not work in base 10 as did BCD. It works in base two. To represent a number like 460.1, it needs three things:</p>
<ul>
<li> the position of the decimal</li>
<li> the information to the left of the decimal</li>
<li> the information to the right of the decimal</li>
</ul>
<p>In our simplified representation, the decimal position is the fourth character. the information to the left is a collection of bits which can be arranged to represent 460. Specifically:</p>
<pre>
460 =
111001100 =
(1*256) + (1*128) + (1 * 64) + (1 * 8) + (1 * 4)
</pre>
<p>So far, everything is exact and we can’t see any room for error, but this is about to change. The only way numbers can be shown on the right hand side of the decimal is to build the reverse version of a binary number. A value must be made up of fractions like:</p>
<p><span class="pre">1/2 + 1/4 + 1/8 + 1/16 + 1/32</span> and so on</p>
<p>As with information to the left of the decimal, there are place holders for items not used. In other words, there is a zero bit if 1/2 is not added to the mix and a 1 bit if it is added to the mix.</p>
<p>In our specific example, the bits needed to link fractions together and come up with “.1” take up a big part of the allocated space for a floating point variable. (Try it yourself!) In fact, so much of the available 80 bits is consumed that there is no longer room for the “460” that goes to the left of the decimal. What can the system do?</p>
<p>At this point, the built-in math routines drop some of the very tiny decimals at the end of the list. (They are so small that they don’t matter anyway.) But in doing so, “.1” ends up being something like “.099999999999999” in the computer’s eyes.</p>
<p>Generally this is converted back to understandable numbers for you. For instance, if you print either of the “.1” values as we did in the example, you will see that Apple’s math package actually printed the correct value.</p>
<p>On the other hand, you can verify that two values which print as the same thing and logically seem to be the same are really different. Let’s make a small addition to the original example so that we can see what is stored in memory:</p>
<p>Hold on. Let’s back up the hexadecimal choo choo here. These numbers are different, but when I print them with a print statement, they look the same!!</p>
<p>So here is a rule that you cannot side step or avoid. PPC math uses approximations of decimals that are usually, but not always, accurate. If you are going to make comparisons between floating point values that come from different types of operations, you are going to have to do things differently. Here are some thoughts on how you might change your current and future math coding.</p>
<p><strong>Don’t use floats for currency.</strong> If you are tracking money, there is no reason to use decimals for dollars (or pounds or yen or whatever). Use pennies instead. One dollar = 100 pennies. A long integer can hold a positive or negative amount of about 2 billion pennies. This translates to a range of -21,474,836.46 to +21,474,836.47. Unless your accounting package is going to top the 21 million dollar mark, you can use longs.</p>
<p><strong>Enlarge and convert to integers before comparing.</strong> If you have to compare floats that are created through different types of operations, multiply them and convert them first. Our example would have worked if we had done it as follows:</p>
<pre>LONG IF INT(myFloat1#*100) = INT(myFloat2#*100)</pre>
