Free Lessons
Courses
Seminars
TechHelp
Fast Tips
Templates
Topic Index
Forum
ABCD
 
Home   Courses   TechHelp   Help   Contact   Merch   Join   Order   Logon   Forums   
 

Math Wrong

By Richard Rost   Richard Rost on LinkedIn Email Richard Rost   4 days ago

Why Computers Get Math Wrong


 S  M  L  XL  FS | Slo Reg Fast 2x Join Now

In today's video, we explain why Math Wrong results like 0.1 + 0.2 can produce unexpected decimals in computers. We will cover binary floating point, rounding, precision limits, equality comparisons, calculation order, IEEE standards, and real-world consequences of numerical errors. We will also discuss how Excel formatting differs from stored values, when to use integers, decimal types, or currency, and how to choose appropriate rounding and comparison tolerances.

Keywords

Tech History, floating point precision, 0.1 + 0.2, IEEE 754, binary representation of decimals, rounding error, floating point equality, Excel precision as displayed, Patriot missile failure, Access Currency vs Double, NaN and infinity, binary64

 

 

 

Start a NEW Conversation
 
Only students may post on this page. Click here for more information on how you can set up an account. If you are a student, please Log On first. Non-students may only post in the Visitor Forum.
 
Subscribe
Subscribe to Math Wrong
Get notifications when this page is updated
 
More Information
Transcript 
Here's a computer doing something that looks ridiculous. 0.1 plus 0.2 equals 0.3, followed by a parade of zeros, then a four. You can build a machine that streams movies, predicts weather, and lands spacecraft, but apparently adding two decimals is where it gives up.

What's going on?

The computer hasn't forgotten how to add. It's working with slightly different numbers from the ones you think you gave it. Usually, the difference is so small that the screen politely hides it, but sometimes that difference escapes and your spreadsheet, database, or program seems to be arguing with elementary school.

Hi, I'm Richard Rost with Computer Learning Zone, and welcome to Tech History. Today we're exploring the tiny compromise hiding inside an enormous amount of computing. We'll see why it happens, how engineers learn to live with it, and when a harmless-looking rounding decision can become a serious problem.

Let's start with something familiar. Divide 1 by 3. You get 0.333, and those 3s keep going. You could spend your life writing 3s and you still wouldn't finish. That's not a broken pencil. It's the limitation of trying to write the fraction as a finite decimal.

Now suppose we stop at 3 decimal places. We write 0.333, multiply that shortened number by 3, and we get 0.999. We're short of 1 because we stopped writing. An endless string of repeating 9s equals 1, but our 3-digit version doesn't. The stopping matters.

Binaries have a similar problem, but usually in binary. We count with 10 digits, 0 through 9. Binary uses just 0 and 1. Think of switches that are either on or off. The rules still make sense, but the numbers that fit neatly change when you change the number system.

After our decimal point, we have tenths, hundredths, thousandths, and so on. After a binary point, the places are halves, quarters, eighths, and smaller powers of 2. A half fits perfectly. So does a quarter. Add them, and three quarters fits perfectly, too. Plenty of computer arithmetic is exact.

But a tenth is awkward in binary. It becomes a repeating pattern like one third did in decimal. That 0.1 on your screen has become a number that wants an endless supply of binary digits. And unfortunately, your computer came with a finite amount of memory. Yes, even the expensive ones.

A number format gives each value limited room. When the digits don't fit, the computer chooses a nearby value that does. In common arithmetic, that means rounding to a representable neighbor. It's like measuring with a ruler whose marks are very, very close together, but still have gaps between them.

The usual stored approximation to 0.1 is a tiny bit larger than an exact tenth. The difference is far beyond the decimal places most people look at. The display may still print 0.1 as a convenient short description of the stored value. A neat display doesn't promise an exact decimal underneath.

0.2 has its own approximation. Add the stored values, round the result to fit, and a Python or JavaScript calculation can display that famous 0.3 with an extra 4 at the end. There isn't a gremlin adding 40 or bill. It's the decimal description of a nearby binary value.

And here's where this gets interesting for programmers. Comparing that result with 0.3 can say false. The values are extremely close, but exact equality asks whether they're identical, not whether a human would reasonably call them the same. That's why an innocent-looking comparison can take your program down the wrong branch.

The name for this family of formats is floating point. Using scientific notation, instead of writing an enormous string of zeros, you keep some important digits and a power that tells you the scale. Binary floating point does something similar using powers of 2. The point effectively floats as the scale changes.

You may have seen this notation on a calculator. A common format, binary 64, uses 64 stored bits. Some describe the sign, some the scale, and the rest help describe the significant part of the number. Don't worry about memorizing the layout. The important idea is that this is a budget. It buys a huge range of values, but not unlimited precision.

Imagine a ruler with a mark for every number your computer can represent. Unlike a regular ruler, though, these marks aren't evenly spaced. The ruler's spacing changes as the numbers get larger. For your small values, neighbors can be incredibly close together. Farther out, the gaps widen. Floating point gives you roughly a fixed supply of significant digits rather than a fixed number of decimal places.

That's useful to remember if you've assumed more zeros means more accuracy. Make a number large enough, and adding one may not change it. That sounds impossible until you remember the gaps. The extra one can be too small to reach the next available value. It's like putting a penny beside a mountain and measuring both with an enormous ruler. The penny isn't zero mathematically. Your measurement can't resolve it.

The order of calculation can matter, too. In exact arithmetic, regrouping additions shouldn't change the answer. With rounded intermediate results, it sometimes does. If you're able to oppose huge values first, then add a small value, and it survives. Add that small value to one huge value first, and it may disappear before the cancellation.

Subtraction has another trap. Subtract almost equal approximations, and their shared leading digits cancel anyway. Any uncertainty already in those values can become a big part of the tiny result left behind. Numerical specialists choose formulas that behave well. Sometimes rearranging a calculation helps more than simply asking for additional digits. The formula matters, not just the hardware.

This wasn't always consistent from one machine to another. Early computer manufacturers made different decisions about the number formats and arithmetic behavior. Creating a scientific program to another computer could bring numerical surprises. Imagine changing cars and discovering that each manufacturer had quietly chosen a different meaning for the marks on the fuel gauge.

Researchers and engineers worked toward common rules. IEEE Standard 754 arrived in 1985 and helped make arithmetic more predictable across systems. It didn't make one tenth fit into a finite binary fraction. A standard can organize the compromise. It can't repeal mathematics.

Those rules also included special values, infinities, and something called NaN, short for not a number. These help software represent certain exceptional results. Applications may expose them differently or report an error instead. They're part of dealing with numerical limits rather than pretending every calculation must produce an ordinary finite answer.

Sometimes there really is a bug. In 1994, a division flaw in early Pentium processors became a major story, and Intel offered replacements. That was a faulty implementation of arithmetic. Our 0.1 example can happen on a perfectly functioning processor. Calling both things floating point problems doesn't give them the same cause or fix.

There's a much more serious lesson from 1991. A Patriot missile battery failed to intercept a Scud that struck a barracks, killing 28 Americans. A government investigation identified a precision problem in the system's timing calculation. That was a real tragedy.

The system counted time in tenths of a second, then converted that count with limited precision. After about 100 hours of continuous operation, the timing error was roughly a third of a second, affecting where it looked for the missile. This wasn't modern binary 64 edition. It was a related lesson about finite precision, conversion, and operating assumptions.

Back to the office, Excel also manages numerical limits, but don't expect our opening example to reveal the same long tail here. Microsoft documents this calculation: 33.1 minus 43.2 plus 1. With enough displayed precision, the result can reveal a tiny difference from 0.9.

Formatting a cell to show two decimal places usually changes what you see, not the stored value. Two cells can look identical, yet behave differently in a later calculation. Think of formatting as a coat of paint on the display. It makes the number easier to read without rebuilding the machinery behind it.

Excel's precision-as-displayed setting goes further. It changes values to match the displayed precision, and Microsoft warns that accuracy can be permanently lost. I wouldn't casually flip that checkbox to make an annoying decimal disappear. Decide what accuracy your work requires, then keep a backup before changes that affect stored data.

For my Microsoft Access students, this is why data types matter. Double is a floating point. Currency uses a scaled integer with four decimal places, which can suit money needing that precision. But formatting a double field as currency doesn't turn it into the Currency data type. A dollar sign is a decoration, not a conversion.

When the problem allows, you can count whole units. Ten cents plus twenty cents is thirty cents using integers. Decimal arithmetic can represent decimal tenths exactly. Neither gives you unlimited accuracy, though. Divide a dollar into three equal parts, and you still need a policy for that leftover cent.

Representation is only part of the job, and different jobs can require different choices. You also have to decide when to round. Round every invoice line, or keep extra precision and round the final total. Those choices can produce different results. The correct choice depends on your business rules. The computer can't guess the policy you intended, and hiding extra digits doesn't communicate it.

Remember to round responsibly. We don't want to end up with that Superman 3 Office Space bug now, do we?

For measurements and scientific calculations, exact equality may be the wrong question. You often want to ask whether results are close enough for the job. A carpenter and a laboratory technician don't use the same acceptable margin. Software needs that context, too.

Tolerance should reflect what you're measuring and how you'll use the result. There isn't one magic tiny number for every comparison. Near zero, an absolute margin may be useful. At large scales, a relative margin can matter. Good tools can combine those ideas, but someone must choose sensible limits. Otherwise, you're replacing one mysterious number with another and hoping it behaves better.

Why keep floating point? It's an extremely useful engineering trade-off. It gives computers a huge numerical range and efficient arithmetic for graphics, simulations, engineering, and everyday calculations. Those applications can work beautifully when their algorithms and error limits are understood. Useful answers don't require pretending that every intermediate value is infinitely precise.

The lesson is to choose the right ruler. Use a suitable data type, understand formatting, decide where rounding belongs, and test calculations with results you already know. For serious numerical work, use methods designed for that problem. When 0.1 plus 0.2 looks strange, you'll know which question to ask first. Careful choices and tests can save plenty of frustration.

Thanks for exploring the world of technology with me. I'll see you next time for another Tech History. I'm Richard Rost with Computer Learning Zone. Live long and prosper.

Thanks for watching. I hope you enjoyed this video. If you're watching on YouTube, make sure you subscribe to my channel and click the bell icon so you get notified anytime I release a new video. And make sure you like and share this video with your friends.

And make sure you stop by my website for lots of free lessons on all kinds of different topics: Microsoft Access, Excel, Word, Windows, and lots more. It's computerlearningzone.com. And I've also got a shorter URL, 599CD.com. That's a long story. But stop by anyway. We hope to see you soon.
Intro 
In today's video, we explain why Math Wrong results like 0.1 + 0.2 can produce unexpected decimals in computers. We will cover binary floating point, rounding, precision limits, equality comparisons, calculation order, IEEE standards, and real-world consequences of numerical errors. We will also discuss how Excel formatting differs from stored values, when to use integers, decimal types, or currency, and how to choose appropriate rounding and comparison tolerances.
Quiz 
Q1. Why can 0.1 not usually be represented exactly in binary floating point?
A. It requires an infinite repeating binary fraction
B. Computers cannot store decimal digits
C. Binary has no fractional values
D. The decimal point is ignored

Q2. What does a computer typically do when a number cannot fit exactly in a floating point format?
A. Stops the calculation
B. Stores the nearest representable value
C. Converts the number to text
D. Stores an unlimited number of digits

Q3. Why might 0.1 + 0.2 display as 0.30000000000000004?
A. The computer added an extra digit by mistake
B. Both decimal values were stored as nearby binary approximations
C. The computer cannot add values smaller than 1
D. The display always adds zeros and a 4

Q4. What does it mean when two floating point values are very close but fail an equality comparison?
A. One of the values must be text
B. They are close, but not stored as exactly identical values
C. The processor has failed
D. The values are too large to compare

Q5. What is the main purpose of floating point representation?
A. To store every decimal value exactly
B. To provide a large numerical range with limited precision
C. To eliminate all rounding decisions
D. To make numbers easier to format as currency

Q6. Why are floating point numbers not evenly spaced across their full range?
A. The spacing gets wider as values get larger
B. Negative numbers have no spacing
C. Only whole numbers can be stored at large values
D. The spacing changes based on the computer's clock speed

Q7. What can happen when adding a very small number to a very large floating point number?
A. The small number may be too small to change the stored result
B. The large number becomes zero
C. Both numbers are converted to integers
D. The calculation always causes an error

Q8. Why can the order of addition affect a floating point result?
A. Addition is not mathematically commutative
B. Intermediate results can be rounded differently
C. Larger numbers are always added last
D. Binary numbers cannot be regrouped

Q9. What is a common danger of subtracting two nearly equal floating point values?
A. The computer changes the result to text
B. Small existing errors can become significant in the remaining result
C. The result always becomes negative
D. The computer automatically rounds to zero

Q10. What did the floating point standard help provide across different computer systems?
A. Identical results for all formulas regardless of precision
B. More predictable numerical formats and arithmetic behavior
C. Exact storage for all decimal fractions
D. Unlimited precision for scientific calculations

Q11. What is NaN generally used to represent?
A. A value that is not an ordinary valid number result
B. A negative whole number
C. A value rounded to the nearest integer
D. A number too small to display

Q12. How was the Pentium division flaw different from the 0.1 + 0.2 example?
A. The Pentium issue was a faulty arithmetic implementation, while 0.1 + 0.2 is normally expected behavior
B. The Pentium issue only affected decimal numbers
C. The 0.1 + 0.2 example only occurs in spreadsheets
D. Both were caused by formatting cells incorrectly

Q13. What was a key lesson from the Patriot missile timing problem?
A. Finite precision and accumulated error can become serious in long-running systems
B. Binary arithmetic should never be used for timing
C. All timing systems should use only whole seconds
D. Formatting values can prevent precision loss

Q14. In Microsoft Excel, what does formatting a cell to show two decimal places usually change?
A. The displayed appearance, not necessarily the stored value
B. The value is permanently converted to two decimal places
C. The value becomes a text string
D. The cell is converted to a currency data type

Q15. What is a risk of using Excel's precision-as-displayed setting?
A. It can permanently discard stored precision
B. It makes formulas calculate infinitely slowly
C. It prevents cells from being formatted
D. It changes all values to text

Q16. Why does formatting an Access Double field as currency not make it a Currency field?
A. Formatting changes display, not the underlying data type
B. Double fields cannot display dollar signs
C. Currency fields are always text fields
D. Access automatically converts all formatted values to integers

Q17. What is often a good approach when working with money in cents?
A. Store and calculate using whole integer units when practical
B. Always use floating point values with many displayed zeros
C. Format all values as currency before calculating
D. Round every value to the nearest dollar

Q18. Why can decimal arithmetic be useful for financial values?
A. Decimal tenths can be represented exactly
B. Decimal arithmetic never requires rounding
C. Decimal values use no memory
D. Decimal arithmetic only works with whole numbers

Q19. Why must a business decide when to round values?
A. Rounding each line item versus rounding a final total can produce different results
B. Computers automatically choose the legally correct method
C. Rounding always produces the same total regardless of timing
D. Currency values cannot be rounded

Q20. What should be used instead of exact equality when comparing measured or calculated floating point values?
A. A tolerance appropriate for the problem
B. A random rounding rule
C. Text comparison
D. A fixed tolerance of zero

Q21. Why might both absolute and relative tolerance be useful?
A. Absolute tolerance can help near zero, while relative tolerance can help at large scales
B. Absolute tolerance is only for text, and relative tolerance is only for dates
C. Relative tolerance always replaces absolute tolerance
D. They are only needed for integer calculations

Q22. What is the central practical lesson about floating point arithmetic?
A. Choose suitable data types, rounding rules, and comparison methods for the job
B. Avoid all calculations involving decimal values
C. Always display as many digits as possible
D. Use exact equality for every calculation

Answers: 1-A; 2-B; 3-B; 4-B; 5-B; 6-A; 7-A; 8-B; 9-B; 10-B; 11-A; 12-A; 13-A; 14-A; 15-A; 16-A; 17-A; 18-A; 19-A; 20-A; 21-A; 22-A

DISCLAIMER: Quiz questions are AI generated. If you find any that are wrong, don't make sense, or aren't related to the video topic at hand, then please post a comment and let me know. Thanks.
Summary 
In this Tech History video, I explain why computers sometimes produce surprising results when working with decimal numbers, such as the familiar example where 0.1 plus 0.2 appears to equal 0.30000000000000004 instead of exactly 0.3.

The computer has not forgotten basic arithmetic. The issue is that most computers store ordinary numbers using binary floating-point formats. We use a decimal number system with digits from 0 through 9, but computers commonly use binary, which uses only 0 and 1. Some decimal fractions, including 0.5, 0.25, and 0.75, can be represented exactly in binary. Other values, especially 0.1 and 0.2, become repeating binary fractions.

This is similar to trying to write one-third as a decimal. One-third becomes 0.333333 and continues forever. If we stop after a few digits, we have only an approximation. Binary has the same limitation with decimal tenths. Since computer memory is finite, the machine has to store a nearby binary value instead of the exact mathematical value.

The approximation used for 0.1 is usually slightly larger than an exact tenth, although the difference is normally far beyond the digits that people see on screen. Likewise, 0.2 is stored as a nearby approximation. When those stored values are added together, the result may be extremely close to 0.3 without being identical to the stored approximation of 0.3. That is why some languages, such as Python and JavaScript, can reveal the extra digits.

This also explains why comparing floating-point values for exact equality can create programming problems. Two values may be close enough for any practical purpose but still fail an exact comparison. Exact equality asks whether the values are identical bit for bit, not whether they are reasonably close according to the needs of the program.

Floating point gets its name from scientific notation. Rather than writing a huge string of zeros, a number can be represented using significant digits and a power that determines its scale. Binary floating point works in a similar way, except that it uses powers of 2. A common format, binary 64, stores a number in 64 bits. Those bits are divided among the sign, the scale, and the significant digits.

This format gives computers a huge range of numbers, but it does not provide unlimited precision. Floating-point numbers are not evenly spaced across the entire number line. Near small values, representable numbers can be incredibly close together. As values become larger, the gaps between neighboring representable values grow wider. Eventually, a value can become so large that adding 1 does not change it because 1 is too small to reach the next available floating-point value.

The order in which calculations are performed can matter as well. In exact mathematics, regrouping additions should not change the result. With rounded intermediate values, however, one order may preserve a small value while another order may lose it. Subtracting nearly equal values can also magnify small errors because the leading digits cancel out, leaving a small result that may contain a relatively large amount of uncertainty.

This is why numerical methods matter. Better formulas and better calculation strategies can often improve results more than simply using more digits. Engineers, scientists, and programmers need to understand the limitations of the data type and choose methods that behave well for the problem they are trying to solve.

Before modern standards, different computer manufacturers often used different floating-point formats and arithmetic rules. Moving scientific software from one machine to another could result in unexpected numerical differences. IEEE Standard 754, introduced in 1985, helped establish common rules for floating-point arithmetic. It made results more predictable across systems, although it could not make values such as one-tenth become finite binary fractions.

The IEEE standard also includes special values such as positive infinity, negative infinity, and NaN, which means "not a number." These values help software handle exceptional conditions rather than pretending that every calculation will always result in an ordinary finite number.

It is important to distinguish normal floating-point behavior from actual hardware defects. The famous 1994 Pentium division bug was an implementation flaw in certain early Intel processors. The 0.1 plus 0.2 issue, on the other hand, can occur on a perfectly functioning computer because it results from the limits of finite binary representation.

Finite precision has also contributed to serious real-world problems. In 1991, a Patriot missile battery failed to intercept a Scud missile that struck a barracks and killed 28 Americans. An investigation determined that the system accumulated a timing error related to limited precision in its conversion of tenths of a second. After approximately 100 hours of continuous operation, the error had grown to roughly one-third of a second, which was enough to affect the system's ability to track the incoming missile. This was not the same as modern binary 64 floating point, but it demonstrates the broader importance of understanding precision, conversion, and long-running calculations.

Spreadsheet programs have their own numerical limitations. In Excel, formatting a cell to display two decimal places generally changes only what you see, not the underlying stored value. Two cells may appear identical while containing slightly different values that can affect later calculations. Formatting is a display choice, not necessarily a data conversion.

Excel also offers a Precision As Displayed option, but that setting actually changes stored values to match their displayed precision. Microsoft warns that this can permanently discard accuracy. I would not use that option simply to hide an annoying decimal result. It is better to decide what precision the work requires and preserve a backup before making changes that alter stored data.

For Microsoft Access users, data types matter for the same reason. A Double field uses floating-point storage. A Currency field uses a scaled integer representation with four decimal places, which is often appropriate for financial values that require that level of precision. Formatting a Double field as currency does not convert it into the Currency data type. Adding a dollar sign to the display is not the same thing as changing how the value is stored.

When appropriate, one solution is to count whole units. Instead of storing dollars and cents as floating-point values, an application can store cents as integers. Ten cents plus twenty cents is exactly thirty cents when represented as whole numbers. Decimal data types can also represent decimal tenths exactly. However, no representation eliminates the need for business rules. If one dollar must be divided among three people, someone still has to decide how to handle the leftover cent.

Rounding policy is often as important as data storage. For example, a business may round each invoice line individually, or it may retain additional precision and round only the final invoice total. Those choices can produce different totals. The correct approach depends on the business rules, legal requirements, and expectations of the people using the system.

For scientific, engineering, and measurement-related work, exact equality is often the wrong test. The better question is whether two results are close enough for the purpose at hand. A carpenter, a machinist, and a laboratory researcher may all need different tolerances. Near zero, an absolute tolerance can be useful. At large scales, a relative tolerance may be more appropriate. There is no single magic tolerance that works for every situation.

Floating point remains extremely useful because it provides enormous range, efficient performance, and sufficient precision for graphics, simulations, engineering, scientific computing, and countless everyday tasks. The important lesson is not that floating point is broken. The lesson is that every numerical representation is an engineering compromise.

Choose the right data type for the job, understand the difference between formatting and stored values, decide where rounding belongs, and test calculations using values whose expected results are known. When 0.1 plus 0.2 produces an unexpected result, you will know that the first question is not whether the computer can add, but how the numbers were represented in the first place.

You can find a complete video tutorial with step-by-step instructions on everything discussed here on my website at the link below. Live long and prosper, my friends.
Topic List 
Why 0.1 + 0.2 may not equal 0.3
Repeating fractions in decimal and binary
Binary fractions and powers of 2
Rounding to nearby representable values
How floating point numbers are stored
Floating point precision and number spacing
Why large numbers lose small additions
Calculation order and rounding errors
Loss of precision from subtracting close values
IEEE floating point standards
NaN and infinity values
Pentium division bug versus floating point limits
Patriot missile timing precision failure
Excel formatting versus stored values
Excel Precision as Displayed setting
Access Double versus Currency data types
Integers and decimal arithmetic for money
Rounding policies for financial calculations
Using tolerances instead of exact equality
Article 
Computers do not make mistakes when they calculate 0.1 plus 0.2. The surprising result, such as 0.30000000000000004, happens because the computer is usually not storing the exact decimal values 0.1 and 0.2. It is storing extremely close binary approximations.

People normally count in base 10, using digits from 0 through 9. After the decimal point, each position represents tenths, hundredths, thousandths, and so on. Computers commonly use binary, which has only two digits: 0 and 1. After a binary point, the positions represent halves, quarters, eighths, sixteenths, and smaller powers of 2.

Some fractions fit perfectly in binary. For example, one half, one quarter, and three quarters can all be represented exactly. But one tenth cannot. Just as one third becomes 0.333333... in decimal, one tenth becomes a repeating pattern in binary. It would require an endless sequence of binary digits to store it exactly.

A computer has limited memory for each number, so it must stop somewhere. It stores the nearest binary value that fits in the available space. That stored value is extremely close to 0.1, but it is not exactly 0.1. The same thing happens with 0.2 and many other decimal fractions.

Most of the time, software hides these tiny differences. A spreadsheet may display 0.1 even though the stored value is slightly larger or smaller than an exact tenth. The displayed value is a convenient rounded description, not necessarily the exact value being used in calculations.

When the stored approximations for 0.1 and 0.2 are added together, the result is another nearby binary value. When that value is converted back to decimal for display, it may appear as 0.30000000000000004. The computer is not adding an extra amount intentionally. It is showing the decimal form of the closest binary result it can represent.

This matters when programs compare values. A calculation such as 0.1 + 0.2 may not be exactly equal to a value entered as 0.3, even though both look like they should be the same to a person. An exact equality comparison asks whether two stored values are identical bit for bit. It does not ask whether they are close enough for the intended purpose.

This behavior is part of floating-point arithmetic. Floating point is designed to represent a very wide range of values efficiently. It works somewhat like scientific notation, where a number has significant digits and a scale. Instead of storing every digit of every number, floating point stores a limited amount of precision along with information about the number's size.

The benefit is that floating point can handle very small and very large values using the same general format. It is useful for scientific work, engineering, graphics, simulations, measurements, and many everyday calculations. The trade-off is that it cannot represent every possible decimal value exactly.

Floating-point values are not spaced evenly across the number line. Near zero, representable values can be extremely close together. As numbers become larger, the gap between neighboring representable values increases. Eventually, a value can become so large that adding 1 does not change it, because 1 is too small to reach the next representable number.

The order of calculations can also affect the result. In exact mathematics, changing the grouping of additions should not matter. With floating point, intermediate results are rounded, so regrouping can sometimes produce slightly different answers. Adding a small value to a very large value may cause the small value to disappear. If large values are subtracted first, a smaller value might survive in the final result.

Subtraction can create another problem called loss of precision. When two nearly equal values are subtracted, many leading digits cancel out. The small result that remains may be strongly affected by tiny errors already present in the original values. This is why numerical calculations often require carefully chosen formulas, not just more decimal places.

Modern computer systems generally follow common rules for floating-point behavior so that calculations are more predictable across hardware and software. Those rules also define special values such as positive infinity, negative infinity, and NaN, which means "not a number." These values help software represent results that cannot be expressed as ordinary finite numbers.

It is important to distinguish normal floating-point behavior from an actual arithmetic defect. A processor bug can produce incorrect results because the hardware implementation is faulty. The 0.1 plus 0.2 example is different. It can happen on a perfectly functioning computer because finite binary storage cannot hold an exact decimal tenth.

Precision issues can matter greatly in systems that run continuously or make critical calculations. A well-known missile-defense failure involved a timing calculation that used limited precision while converting tenths of a second into another form. Over many hours of operation, the small error accumulated enough to affect the system's tracking. The lesson is not that floating point is inherently unsafe. The lesson is that engineers must understand the limits of the number representation and account for error over time.

In Microsoft Excel, formatting can hide or reveal these effects. A cell formatted to show two decimal places may display 0.30 even if the stored value contains additional digits. Changing the format changes what you see, not necessarily the value Excel stores and uses in later calculations.

That means two cells can look identical but still behave differently in formulas. For example, one cell may contain an exact value entered as 0.9, while another may contain a calculated value that is extremely close to 0.9 but not identical. If a formula compares those cells for exact equality, the result may be unexpected.

Excel includes an option called precision as displayed. This forces stored values to match the visible number of decimal places. It can make certain calculations appear cleaner, but it permanently changes the stored data and can discard accuracy. It should not be used casually just to hide a floating-point annoyance. Always keep a backup before making a change that alters stored values.

In Microsoft Access, choosing the correct data type is especially important. A Double field uses floating-point storage. It is useful for measurements, scientific values, and calculations where tiny approximation differences are acceptable. A Currency field uses a fixed number of decimal places and is often more appropriate for money values that need consistent precision to four decimal places.

Formatting a Double value with a dollar sign does not convert it into Currency. Formatting affects appearance. The underlying data type determines how the value is stored and calculated.

For money, one practical approach is to store values as whole smallest units whenever possible. Instead of storing $10.25 as a floating-point number, store 1025 cents as an integer. Addition and subtraction of whole integers are exact as long as the values remain within the available range. This approach avoids many floating-point issues.

Decimal data types can also represent decimal fractions such as tenths and hundredths exactly. They are useful when decimal accuracy matters, including financial and accounting calculations. However, decimal arithmetic does not solve every problem. Dividing one dollar among three people still produces a fraction of a cent, so a business rule is needed to decide how the remainder should be handled.

Rounding is a business decision as much as a technical one. For example, an invoice may require each line item to be rounded to cents before the total is calculated. Another business may keep additional precision for each item and round only the final total. These methods can produce different results. Neither is automatically correct. The correct choice depends on the rules that apply to the situation.

For measurements and scientific calculations, exact equality is often the wrong test. Instead of asking whether two values are identical, ask whether they are close enough for the job. A carpenter, a laboratory technician, and an aerospace engineer may all need different acceptable tolerances.

A useful comparison may combine an absolute tolerance and a relative tolerance. An absolute tolerance is helpful near zero, where even a small difference may matter. A relative tolerance is helpful for larger values, where an acceptable difference may depend on the size of the values being compared. The tolerance should be chosen based on the meaning of the data, the expected error, and the consequences of being wrong.

If a program needs to compare calculated decimal values, the code should generally determine whether the difference between the values falls within an appropriate tolerance rather than checking for exact equality. For money, the code should use a suitable fixed-decimal or integer representation and apply rounding according to the organization's rules. For spreadsheets and databases, calculations should be tested with known examples, especially cases involving totals, taxes, discounts, percentages, and repeated calculations.

Floating point is not a flaw in computers. It is a practical compromise that provides speed, enormous range, and useful accuracy for many kinds of work. The key is to choose the right number type, understand when values are approximate, decide where rounding belongs, and test calculations that matter.

When 0.1 plus 0.2 produces an unexpected-looking result, the computer has not forgotten elementary arithmetic. It is simply using a different ruler than the one people use when they write decimal numbers.
Primary Topics 
binary floating point, decimal-to-binary representation limits, rounding and precision, floating-point equality comparisons, numerical stability, IEEE floating-point standards, Excel number storage, Access data types
Secondary Topics 
scientific notation, representable-number spacing, loss of significance, catastrophic cancellation, calculation order, infinity and NaN, Patriot missile timing error, Pentium division flaw, integer arithmetic, decimal arithmetic, rounding policy, absolut
 
 
What's This?

 

The following is a paid advertisement
Computer Learning Zone is not responsible for any content shown or offers made by these ads.
 

Learn
 
Access - index
Excel - index
Word - index
Windows - index
PowerPoint - index
Photoshop - index
Visual Basic - index
ASP - index
Seminars
More...
Customers
 
Login
My Account
My Courses
Lost Password
Memberships
Student Databases
Change Email
Info
 
Latest News
New Releases
User Forums
Topic Glossary
Tips & Tricks
Search The Site
Code Vault
Collapse Menus
Help
 
Customer Support
Web Site Tour
FAQs
TechHelp
Consulting Services
About
 
Background
Testimonials
Jobs
Affiliate Program
Richard Rost
Free Lessons
Mailing List
PCResale.NET
Order
 
Video Tutorials
Handbooks
Memberships
Learning Connection
Idiot's Guide to Excel
Volume Discounts
Payment Info
Shipping
Terms of Sale
Contact
 
Contact Info
Support Policy
Mailing Address
Phone Number
Fax Number
Course Survey
Email Richard
[email protected]
Blog RSS Feed    YouTube Channel

LinkedIn
Copyright 2026 by Computer Learning Zone, Amicron, and Richard Rost. All Rights Reserved. Current Time: 11/14/2026 12:58:32 AM. PLT: 0s
Keywords: Tech History, floating point precision, 0.1 + 0.2, IEEE 754, binary representation of decimals, rounding error, floating point equality, Excel precision as displayed, Patriot missile failure, Access Currency vs Double, NaN and infinity, binary64  PermaLink  Why Computers Get Math Wrong - Tech History