As Quatro Operacoes

Arithmetic basics that still trip people up in practice

The four fundamental operations in mathematics are addition, subtraction, multiplication, and division. Most people learn them in elementary school and never think about them again. But when you're actually applying them to real data, spreadsheets, or financial models, things get messy fast. I've seen the same mistakes repeat for years. Addition combines quantities. Subtraction finds the difference. Multiplication scales. Division partitions. That's the textbook version. Here's the version that matters when you're working: Addition order doesn't matter for most practical purposes, which is why it's commutative. But floating-point arithmetic in computers doesn't always respect that. If you add a billion small decimals to one large number, the small ones can get swallowed. Add them in ascending order instead, and you'll get different results. Not always, but often enough to notice.

Subtraction is where people get sloppy with signs. I once spent three hours debugging a budget script because someone subtracted expenses from revenue in the wrong order across two columns. The numbers looked reasonable at a glance. They were completely backwards. Always check which operand is the minuend and which is the subtrahend. One swapped column and your variance is negative when it should be positive, or vice versa. Multiplication has the hidden complexity of decimal precision. Multiply 2.5 by 3.1 and you get 7.75. Simple. Multiply 0.1 by 0.2 in most programming languages and you might get 0.020000000000000004. This isn't a bug, it's binary representation. Floats can't exactly represent most decimal fractions. Use a decimal library or round explicitly if your application depends on exact results. Financial calculations absolutely should use fixed-point or decimal types, not floats. Division is where errors become catastrophic. Division by zero crashes programs and skews statistics. Integer division truncates instead of rounding, so 5 / 2 gives you 2 in many languages, not 2.5. I've seen integer division silently produce wrong quantities in inventory systems. The fix is usually explicit type casting: (double) 5 / 2, or using a decimal context that returns fractional results.

There's also the order of operations problem. Most people memorize PEMDAS or BODMAS, but the practical issue comes when people write expressions without considering how their tool interprets them. Excel, Python, and a calculator can give different answers for the same written expression if you don't account for precedence rules. When in doubt, use parentheses. They're not decorative, they're mandatory in ambiguous situations.

Operation sequence in real work

Start with whatever operation your data needs first, not whatever looks easiest. In a spreadsheet calculating final prices after tax and discounts, you have to apply the discount before the tax, or the math is wrong. People sometimes take the lazy route and layer operations in the wrong sequence, then wonder why their totals don't reconcile. Chain your operations deliberately. Write intermediate results into separate cells or variables. It costs almost nothing in time and it makes debugging ten times faster. When your final number is off by one percent, you want to know whether it's the discount calculation, the tax calculation, or the combination that's broken. You won't find that by looking at one formula that does everything at once. Also worth noting: repeated subtraction is slower than multiplication, and repeated addition is slower than multiplication for larger counts. If you're iterating through data, multiplicative shortcuts will cut your processing time significantly. I replaced a loop that subtracted a value 1,200 times per record with a single multiplication, and a batch job that took forty minutes dropped to under three.

Division has a practical edge case worth remembering. When dividing by a value computed from your data, always check for zero or near-zero values before the division happens. A user with no prior purchases generates a zero count. Try to divide by that and your program either errors out or produces an infinite result that corrupts downstream calculations. Guard against it at the input stage, not after.