Forem: Aditya Srivastava

Why 0.1 + 0.2 isn't always 0.3 : Floating Point Explained

Aditya Srivastava — Wed, 18 Jun 2025 11:04:45 +0000

Go ahead and type out 0.1 + 0.2 in your IDE. You expect 0.3, but instead, you get 0.30000000000000004. You stare at the screen, knowing something’s off. Is your computer broken? Is your code faulty? Well, news flash, it's intentional and it's all a part of floating point arithmetic. In this blog, we’ll look into why floating-point numbers behave this way, how computers represent them, and the real-world situations where precision is critical.

Let’s start with a quick experiment. Run this Python code:

print(0.1 + 0.2)
# Output: 0.30000000000000004

Notice that tiny 0.00000000000000004 trailing at the end of 0.1 + 0.2? That’s not a bug—it’s a fundamental quirk of how computers deal with decimal numbers. Computers don’t naturally understand decimals the way humans do; they speak binary, and most decimal numbers, like 0.1, are messy in that world. Enter floating-point arithmetic, the system computers use to approximate real numbers (like 3.14 or 0.001). It’s a clever workaround, but it comes with a catch: it's not precise. Because computers can’t store most decimals exactly, these tiny errors can lead to surprising results.

Why Precision Is an Illusion

To understand why 0.1 + 0.2 might not always be 0.3, let’s think about fractions.

(pardon the shit hand writing)

If you limit precision to, say, four decimal places, you get 0.9999 instead of 1. Computers face a similar problem when converting decimal numbers to binary. Numbers like 0.1 and 0.2 look simple in base-10, but in binary, they become infinite repeating fractions. For example:

0.1 in binary is approximately 0.000110011001100...
0.2 in binary is approximately 0.00110011001100...

Computers use a finite number of bit's to store these numbers, so they’re rounded off, leading to small errors. When you add 0.1 + 0.2, those tiny errors combine, giving you 0.30000000000000004.

The IEEE 754 Standard

How do computers manage to store a vast, infinite range of numbers with just a handful of bits? Meet the IEEE 754 standard, the clever blueprint behind floating-point arithmetic in nearly all modern computers. Think of IEEE 754 as a clever packing system that squeezes an infinite range of numbers into just 32 or 64 bits.

Let’s break down how IEEE 754 works with a simplified 32-bit example (real systems often use 64 bits for more precision):

Sign bit (1 bit): Indicates positive (0) or negative (1).
Exponent (8 bits): Represents the scale of the number (like (2^n) in scientific notation).
Mantissa (23 bits): Stores the significant digits.

The catch? Only a limited number of bits are available, so most numbers are approximations. IEEE 754 also defines special values like:

NaN (Not a Number): For invalid operations like 0/0.
Infinity: For numbers too large to represent.
-0: A negative zero, distinct from positive zero.

The biased exponent in IEEE 754 adds a constant (like 127 for 32-bit) to the raw exponent, shifting it to a positive range for storage. This allows representation of both positive and negative powers of 2 within the 8-bit exponent field.

(this blog ain't about IEEE-754 cause that's a big topic to go into by itself but there's a very cool video explaining such compression algorithms for anyone interested linked at the end)

Real-World Impacts of Floating-Point Errors

You might think, “Who cares about a tiny error like 0.00000000000000004?” For many applications, like video games or weather simulations, these errors are negligible. But in some fields, they can be catastrophic. Here are some real-world examples:

1. Financial Systems

In finance, tiny floating-point errors can add up fast. A bank processing millions of transactions might see small discrepancies, like 0.1 + 0.2 yielding 0.30000000000000004, causing significant losses or overcharges. To avoid this, financial systems often use fixed-point arithmetic or specialised libraries for exact decimal calculations.

2. Scientific Computing

In scientific simulations, like climate modelling, floating-point errors can distort results. Small miscalculations in iterative processes may predict clear skies when a storm is coming. Scientists use high-precision formats and error-correction methods to minimise these issues.

3. Aerospace and Engineering

In aerospace, precision is critical. The 1991 Patriot Missile failure, where a 0.1-second timing error grew due to floating-point rounding in a 24-bit system, led to a deadly miss.

4. Machine Learning

Machine learning models perform billions of calculations, and floating-point errors can affect accuracy. Using lower-precision formats for efficiency can lead to unstable training, so techniques like mixed-precision training balance speed and reliability.

Handling Floating-Point Errors

Those tiny errors, like 0.1 + 0.2 giving 0.30000000000000004, can trip you up. Here’s how to stay out of trouble:

Use fixed-point arithmetic or decimal libraries for money-related stuff where precision is critical.
Avoid comparing floats directly. Check if the difference is within a small epsilon (like 0.000000001).
Use higher precision types (like float64) when accuracy matters more than speed.
Test carefully when building systems that rely on precision, like aerospace or scientific applications.

Conclusion

Floating-point arithmetic isn’t a perfect. It’s more like a clever negotiation between your code and the computer’s binary brain. That annoying 0.00000000000000004 when adding 0.1 + 0.2 shows the system’s limits, but the IEEE 754 standard still manages to cram an infinite range of numbers into a few bits.

CORS : The Browser Bouncers Explained

Aditya Srivastava — Wed, 21 May 2025 17:13:29 +0000

Why You Should Know About CORS

Knowing CORS inside out doesn’t just make you feel smarter—it’s critical for building secure systems on the internet.

Cross-Origin Resource Sharing (CORS) is like a big bouncer at the gate of your browser’s exclusive club, saying:

“SORRY, YOU’RE NOT ON THE LIST.”

...to any uninvited requests.

There are many ways to learn about CORS. In this blog, we’re ditching the frontend perspective (and the cybersecurity deep dive) to focus on:

What CORS actually does
Why it exists
How you—the backend dev—are in charge of making it behave

The Same-Origin Policy (SOP)

Before diving into CORS, let’s cover why it exists.

The Same-Origin Policy (SOP) is a browser-enforced security rule that restricts how sites (technically, origins) interact. Without it, a site like cutecatphotos.com could make requests to your bank’s website and read private data just because you’re logged in. Not good.

In short: SOP prevents websites from reading data from another site unless they share the same origin.

What’s an “Origin”?

An origin combines:

Scheme (e.g., http, https)
Host (e.g., example.com)
Port (e.g., :3000)

Even a slight difference in any of these creates a different origin.

The browser only allows full access between resources from the same origin.

See the table below to understand what counts as “same origin”:

SOP Blocks Reads, Not Writes

A common misconception: SOP doesn’t stop websites from sending data to other origins—only from reading the response.

Your app can still:

Send a POST request
Embed an image, script, or stylesheet from another origin
Submit a form to a different domain

Why is this okay? Because you’re not seeing what comes back—you’re just tossing data over the wall.

Try reading the response with fetch() or XMLHttpRequest? Blocked—unless the server explicitly allows it via CORS.

A Quick Analogy

Think of SOP as sending a letter. You can mail it anywhere, no problem. But reading the reply? That’s locked—unless the recipient says:

“Yep, you’re allowed to read this.”

That’s where CORS comes in.

What is CORS?

Cross-Origin Resource Sharing (CORS) is the guest list for your browser’s club. It’s how a server tells the browser:

“Hey, this site is cool—let them read my stuff.”

SOP blocks JavaScript from reading responses from other origins by default. CORS is the exception—the permission slip that tells the browser it’s safe to share.

How Does CORS Work?

When your browser tries to fetch data from a different origin, it sends an HTTP request with an Origin header, identifying where the request came from.

The server checks this origin against its “allowed list” and responds with headers like:

Access-Control-Allow-Origin: Which origin(s) can access the resource
Access-Control-Allow-Credentials: Whether cookies/credentials are allowed

If the server gives the green light, the browser lets your JavaScript access the response. If not, the browser blocks it and throws a CORS error in the console.

The Flow of a CORS Request

CORS requests typically follow one of two flows: simple or preflighted.

Simple CORS Request Flow

A simple request is a cross-origin GET, POST, or HEAD request using only basic headers (e.g., Content-Type: text/plain).

Flow:

The browser adds an Origin header to the request.
The server checks the Origin and, if allowed, responds with: Access-Control-Allow-Origin: <origin>.
The browser inspects the response. If the header is present and matches, JavaScript can read the response; otherwise, it’s blocked with a CORS error.

Even simple requests are subject to CORS enforcement if the response lacks proper headers.

Preflighted CORS Request Flow

A preflight request occurs when the browser sends an OPTIONS request to check if the actual request is safe. This happens for methods other than GET, POST, or HEAD, or when custom headers are used.

Flow:

The browser sends an OPTIONS request with Origin, Access-Control-Request-Method, and Access-Control-Request-Headers.
The server responds with allowed origins, methods, and headers via:
- Access-Control-Allow-Origin
- Access-Control-Allow-Methods
- Access-Control-Allow-Headers
If the preflight response allows it, the browser sends the actual request.
The server responds with the data, including Access-Control-Allow-Origin.
The browser allows JavaScript to read the response only if headers match; otherwise, it throws a CORS error.

This extra step ensures servers are protected from unsafe requests by verifying permissions first.

Dynamic Origin Whitelisting: Don’t Let Your CORS Be a Pushover

Imagine your server’s a VIP club, and CORS is the bouncer checking IDs. If the bouncer just trusted every ID without a guest list, you’d have chaos. That’s what happens when you blindly set Access-Control-Allow-Origin to any origin that knocks. Let’s break down why this is a rookie mistake and how to lock it down.

The Rookie Mistake: Blindly Trusting Origins

Here’s the kind of code that you don't want to write:

res.setHeader("Access-Control-Allow-Origin", req.headers.origin);

This is like your bouncer saying, “Sure, shadyhacker.com, you’re legit!” It takes the Origin header from any request and mirrors it back. Why’s this bad? Because anyone can fake an Origin header. A malicious site like evil.com could get approved and read your server’s response, potentially stealing sensitive data like user info or session tokens. It’s like handing out backstage passes to every rando in the crowd.

The Pro Gamer Move: Whitelist Like You Mean It

As the backstage manager, only let trusted origins in with a whitelist:

const whitelist = ["https://trusted.com"];
const origin = req.headers.origin;
if (origin && whitelist.includes(origin)) {
  res.setHeader("Access-Control-Allow-Origin", origin);
  res.setHeader("Vary", "Origin");
}

This code is your bouncer with a clipboard, checking every origin against a VIP list. Only https://trusted.com gets in. If dodgy.net tries to sneak through? Access denied. The browser sees no Access-Control-Allow-Origin (or one that doesn’t match), and the response stays locked.

Pro tip: Hardcode the whitelist or load it from a secure config. Never let user input touch it. Keep the list tight—every extra origin is another

door left ajar.

Practical Backend Guidelines: Be the Boss of Your CORS

You’re running the show, so don’t let CORS be the weak link that trashes your club. Here are five golden rules to keep your server secure and users happy:

1. Always Validate the Origin

Never trust the Origin header blindly. Use a whitelist to check every request. If the origin isn’t on your VIP list, don’t set Access-Control-Allow-Origin. This keeps shadyhacker.com out.

2. Don’t Use `*` with Credentials

Setting Access-Control-Allow-Origin: * is like leaving the club door wide open—fine for public data, but a disaster with cookies or auth tokens. If you need Access-Control-Allow-Credentials: true, specify an exact origin (e.g., https://trusted.com). Mixing * with credentials? The browser will block the request.

const whitelist = ["https://trusted.com"];
const origin = req.headers.origin;
if (origin && whitelist.includes(origin)) {
  res.setHeader("Access-Control-Allow-Origin", origin);
  res.setHeader("Access-Control-Allow-Credentials", "true");
  res.setHeader("Vary", "Origin");
}

Misconceptions About CORS: Don’t Get It Twisted

CORS can be tricky, and plenty of devs get the wrong idea. Let’s clear up some myths so you don’t look like a rookie at the next dev meetup.

CORS Isn’t About Authentication or Authorization

CORS doesn’t care who’s logged in or if they have the right API key. It’s just the browser checking if one origin can read data from another. Your server still needs to handle auth and permissions. Think of CORS as the club’s guest list, not the VIP pass—your backend still checks IDs at the bar.

CORS Protects the Browser, Not Your Backend

CORS is a browser mechanism, not a server fortress. It stops shadyapp.com from reading your server’s response in a user’s browser, but it doesn’t stop requests from hitting your server. Your backend needs proper auth to keep the riffraff out.

Non-Browser Clients Don’t Care About CORS

Tools like curl or Postman ignore CORS entirely—they’re not browsers. They’ll hit your server and get the response, no questions asked. This is why CORS alone isn’t enough for security—it’s like expecting the bouncer to stop people sneaking through the back alley.

Pro tip: Assume your server’s getting hit directly. CORS is the browser’s gatekeeper, not your backend’s bodyguard.

Conclusion: CORS is Negotiation, Not Defense

CORS isn’t your server’s shield—it’s a handshake between your backend and the browser, ensuring safe cross-origin sharing. As the backend boss, you write the guest list, deciding who reads your data and how. Get it right, and you enable smooth, secure apps that play nice across domains. Get it wrong, and you’re either locking out legit users or letting evil.com sneak into the VIP lounge.

Understanding CORS doesn’t just make you a better dev—it saves you from those soul-crushing “CORS error” bug reports and keeps your app’s users dancing. So, set those headers, test your setup, and run your club like a pro. Your server’s got this.

Conclusion

This was my first try at writing a technical blog and I am by no means an expert in the field, this is just a topic I happened to dive deeper into than I needed to and wanted to share what I thought might help.
Still I hope you guys enjoyed it :)

Forem: Aditya Srivastava

Why 0.1 + 0.2 isn't always 0.3 : Floating Point Explained

Why Precision Is an Illusion

The IEEE 754 Standard

Real-World Impacts of Floating-Point Errors

1. Financial Systems

2. Scientific Computing

3. Aerospace and Engineering

4. Machine Learning

Handling Floating-Point Errors

Conclusion

Further Reading

CORS : The Browser Bouncers Explained

Why You Should Know About CORS

The Same-Origin Policy (SOP)

What’s an “Origin”?

SOP Blocks Reads, Not Writes

A Quick Analogy

What is CORS?

How Does CORS Work?

The Flow of a CORS Request

Simple CORS Request Flow

Flow:

Preflighted CORS Request Flow

Flow:

Dynamic Origin Whitelisting: Don’t Let Your CORS Be a Pushover

The Rookie Mistake: Blindly Trusting Origins

The Pro Gamer Move: Whitelist Like You Mean It

Practical Backend Guidelines: Be the Boss of Your CORS

1. Always Validate the Origin

2. Don’t Use `*` with Credentials

Misconceptions About CORS: Don’t Get It Twisted

CORS Isn’t About Authentication or Authorization

CORS Protects the Browser, Not Your Backend

Non-Browser Clients Don’t Care About CORS

Conclusion: CORS is Negotiation, Not Defense

Further Reading

Conclusion

Forem: Aditya Srivastava

Why 0.1 + 0.2 isn't always 0.3 : Floating Point Explained

Why Precision Is an Illusion

The IEEE 754 Standard

Real-World Impacts of Floating-Point Errors

1. Financial Systems

2. Scientific Computing

3. Aerospace and Engineering

4. Machine Learning

Handling Floating-Point Errors

Conclusion

Further Reading

CORS : The Browser Bouncers Explained

Why You Should Know About CORS

The Same-Origin Policy (SOP)

What’s an “Origin”?

SOP Blocks Reads, Not Writes

A Quick Analogy

What is CORS?

How Does CORS Work?

The Flow of a CORS Request

Simple CORS Request Flow

Flow:

Preflighted CORS Request Flow

Flow:

Dynamic Origin Whitelisting: Don’t Let Your CORS Be a Pushover

The Rookie Mistake: Blindly Trusting Origins

The Pro Gamer Move: Whitelist Like You Mean It

Practical Backend Guidelines: Be the Boss of Your CORS

1. Always Validate the Origin

2. Don’t Use * with Credentials

Misconceptions About CORS: Don’t Get It Twisted

CORS Isn’t About Authentication or Authorization

CORS Protects the Browser, Not Your Backend

Non-Browser Clients Don’t Care About CORS

Conclusion: CORS is Negotiation, Not Defense

Further Reading

Conclusion

2. Don’t Use `*` with Credentials