Decimal numbers are just fractions written differently
I ran into this problem years ago when I was building a financial transaction system. We needed to store dollar amounts precisely, and the standard floating-point representation kept losing cent values through rounding errors. That's when I really understood how decimals work under the hood. A decimal number is simply a number that uses a base-10 positional notation with a fractional part represented after a dot. The digits to the left of the dot are whole units, and the digits to the right represent increasingly smaller fractions: tenths, hundredths, thousandths, and so on. So 3.75 means three whole units plus seventy-five hundredths, which is the same as three and three-quarters.
o que são os numeros decimais na prática
Here's something most people miss: the position of each digit after the dot follows powers of ten. The first position is 10¹ (tenths), the second is 10² (hundredths), the third is 10³ (thousandths). Each position to the right divides by ten again. This is why 0.01 is ten times smaller than 0.1 and one hundredth of 1. Decimals are just another way to write fractions where the denominator is a power of ten. 0.25 equals 25/100 or one quarter. 0.5 equals 5/10 or one half. You convert between them by counting the digits after the dot—if there are two digits, the denominator is 100, if three digits it's 1000, and so on.
In the real world, this shows up everywhere. Money uses decimals constantly: $12.50 is twelve dollars and fifty cents, or 1250 cents. Measurements use them: 1.5 meters, 0.75 kilograms, 2.25 liters. Science and engineering rely heavily on decimal precision, and calculators display results in decimal form rather than fractions because it's easier to read at a glance. But there's a fundamental problem I encountered when working with floating-point numbers in code. The system actually stores numbers in binary, not decimal, which creates representation issues. For example, 0.1 in binary becomes a repeating fraction that can't be stored exactly, so operations like 0.1 + 0.2 produce 0.30000000000000004 instead of the expected result. When building financial systems, I always worked around this by storing money as integers representing cents rather than using floating-point decimals.
This isn't unique to computers. Decimal fractions have limits too. 1/3 equals 0.333333... repeating infinitely, and you can't represent it exactly with a finite number of decimal places. You either truncate it or accept approximation. Binary representations face the same issue—some fractions that look clean in decimal become infinite repetitions in binary, like how 0.1 in decimal has no exact binary equivalent. When comparing decimals, you align them by the dot and compare digit by digit from left to right. The number with the larger digit at the first differing position is greater. So 2.5 is bigger than 2.49 because 5 in the tenths place exceeds 4 in the tenths place, regardless of how many digits follow. It's easy to mistakenly think 2.49 is larger simply because it has more digits, but that's incorrect—the value depends on position, not count.
👉 Clique no botão abaixo para saber mais sobre o assunto!
For arithmetic operations, addition and subtraction require aligning the decimal points, just like you'd align columns for whole numbers. Multiplication works differently: multiply the numbers as if they were whole, then count the total digits after the dots in both factors and place the dot that many positions from the right in your result. So 1.5 times 0.25 becomes 15 times 25 equals 375, with three total decimal places across the factors, giving you 0.375. Decimals come in different types. Terminating decimals like 0.25 end after a finite number of places. Repeating decimals like 0.333... have a pattern that goes on forever. Irrational numbers like or 2 have decimals that never repeat or terminate. Terminating and repeating decimals are both rational—they can be expressed as fractions. Irrationals cannot.
Converting fractions to decimals usually means dividing the numerator by the denominator. Most calculators do this automatically, but understanding the long division process helps you catch errors when software gives unexpected results. When I encountered rounding issues in a Python financial application, I learned to use specialized libraries like Python's decimal module, which stores numbers in base 10 exactly the way humans expect, rather than relying on standard float operations. Some practical applications I've found useful involve unit conversions between measurement systems, scientific notation for very large or small numbers, percentage calculations as decimals, and statistical analysis where results naturally produce long decimal strings. Decimals make it easier to visualize quantities and compare values quickly, though you need to be careful about precision and rounding—always specifying how many decimal places you're working with and understanding the trade-offs between accuracy and usability.
Rounding rules are straightforward: if the next digit is 5 or greater, round up; otherwise round down. So 3.75 rounded to one decimal place becomes 3.8 since 5 triggers an upward round. This matters in financial calculations where a rounding difference of a few cents across thousands of transactions adds up. The convention varies by context, but consistent application prevents small errors from compounding over time. NaN errors come from invalid operations like dividing zero by zero or taking the square root of negative numbers. I've seen these crash financial models before, so I always add validation checks to catch edge cases and handle them explicitly rather than letting the system propagate meaningless values downstream.
The key insight is that decimal representation is a human convention, not a mathematical truth. Its limitations in binary systems mean we need to be intentional about precision—whether we're doing simple arithmetic or building systems that handle money or scientific calculations.