Brevity: what "be brief" does to answers

How much shorter a model answers a concrete question when the prompt ends with

Be brief - use as few words as possible to express your thoughts.

and whether the answer stays correct.

Words per model

Sum over the 10 questions of the median words per question; call time is the median over all calls of the arm.

modelplainbriefbrief / plaincorrect repliesmedian call, plain → brief
claude-haiku-4-51,3312770.2160/606 s → 3.7 s
gpt-5.6-terra5011210.2460/605.9 s → 4.7 s
claude-opus-51,4021440.160/605.3 s → 2.8 s
claude-opus-5-51,6932670.1660/605.2 s → 3.2 s

Words without the modifier

claude-haiku-4-51,331
gpt-5.6-terra501
claude-opus-51,402
claude-opus-5-51,693

Words with the modifier

claude-haiku-4-5277
gpt-5.6-terra121
claude-opus-5144
claude-opus-5-5267

Words per question

Median words, plain → brief.

questionclaude-haiku-4-5gpt-5.6-terraclaude-opus-5claude-opus-5-5
pg-port
What is the default port of PostgreSQL?
51 → 15 → 11 → 128 → 1
git-undo-commit
How do I undo my last git commit but keep its changes?
127 → 3145 → 16113 → 14126 → 30
float-sum
Why does 0.1 + 0.2 not equal 0.3 in JavaScript?
163 → 3481 → 28262 → 34317 → 59
http-429
Which HTTP status code means that the client sent too many requests?
94 → 225 → 433 → 464 → 4
docker-running
How do I list the running Docker containers?
130 → 1812 → 310 → 8101 → 8
tcp-vs-udp
What is the difference between TCP and UDP?
168 → 4793 → 14258 → 16316 → 36
sort-stable
Is Python's list.sort() stable?
151 → 2347 → 1077 → 1133 → 14
uptime-downtime
A service promises 99.9% uptime. How much downtime does that allow in a 30-day month?
74 → 1521 → 439 → 635 → 5
idempotent
What does it mean for an HTTP method to be idempotent?
199 → 5398 → 20316 → 39299 → 73
money-type
Should I store money amounts in PostgreSQL as float or as numeric?
174 → 3394 → 21293 → 21274 → 37

Replies

Every reply the tables are built from, by question, model and arm.

pg-port: What is the default port of PostgreSQL?

Reference answer: 5432

claude-haiku-4-5

plain
rep 1: 71 words
# Default PostgreSQL Port The default port for PostgreSQL is **5432**. This is the standard port that PostgreSQL listens on for incoming client connections. You can specify a different port during installation or by modifying the `postgresql.conf` configuration file, but 5432 is the convention used by most PostgreSQL installations. When connecting to a PostgreSQL database, if no port is specified, most tools and drivers will automatically attempt to connect to port 5432.
rep 2: 51 words
The default port for PostgreSQL is **5432**. This is the standard port that PostgreSQL listens on when it's installed and configured with default settings. However, PostgreSQL can be configured to listen on different ports if needed by modifying the `postgresql.conf` configuration file or specifying a different port when starting the server.
rep 3: 33 words
The default port for PostgreSQL is **5432**. This is the standard port that PostgreSQL listens on for client connections, unless it has been configured differently during installation or in the PostgreSQL configuration files.
brief
rep 1: 1 words
5432
rep 2: 7 words
The default port for PostgreSQL is **5432**.
rep 3: 1 words
5432

gpt-5.6-terra

plain
rep 1: 5 words
PostgreSQL’s default port is **5432**.
rep 2: 5 words
PostgreSQL’s default port is **5432**.
rep 3: 5 words
PostgreSQL’s default port is **5432**.
brief
rep 1: 1 words
5432
rep 2: 1 words
5432
rep 3: 1 words
5432

claude-opus-5

plain
rep 1: 1 words
5432
rep 2: 1 words
5432
rep 3: 1 words
5432
brief
rep 1: 1 words
5432
rep 2: 1 words
5432
rep 3: 1 words
5432

claude-opus-5-5

plain
rep 1: 29 words
PostgreSQL's default port is **5432** (TCP). You can change it with the `port` setting in `postgresql.conf`. To check the port on a running server, run `SHOW port;` in `psql`.
rep 2: 26 words
PostgreSQL's default port is **5432** (TCP). You can change it with the `port` setting in `postgresql.conf`, and connect to a non-default port using `psql -p <port>`.
rep 3: 28 words
PostgreSQL listens on TCP port **5432** by default. You can change it with the `port` setting in `postgresql.conf`, or override it when connecting (for example, `psql -p 5433`).
brief
rep 1: 1 words
**5432**
rep 2: 1 words
5432
rep 3: 1 words
**5432**
git-undo-commit: How do I undo my last git commit but keep its changes?

Reference answer: git reset --soft HEAD~1

claude-haiku-4-5

plain
rep 1: 119 words
# Undo Last Git Commit (Keep Changes) Use **`git reset --soft HEAD~1`** ```bash git reset --soft HEAD~1 ``` This will: - ✅ Undo the last commit - ✅ Keep all your changes staged (ready to commit again) - ✅ Keep the changes in your working directory ## Variations | Command | Result | |---------|--------| | `git reset --soft HEAD~1` | Changes stay **staged** | | `git reset --mixed HEAD~1` | Changes are **unstaged** (default) | | `git reset HEAD~1` | Same as `--mixed` | | `git reset --hard HEAD~1` | ⚠️ **Discards changes** (be careful!) | ## Example ```bash # Check your status git status # Undo last commit, keep changes staged git reset --soft HEAD~1 # Your changes are now staged and ready to re-commit git status ``` **Tip:** If you've already pushed the commit, you'll also need `git push --force` after resetting (use with caution on shared branches).
rep 2: 142 words
# Undo Last Commit, Keep Changes You have two main options depending on whether you want the changes staged or unstaged: ## Option 1: Keep changes **staged** (ready to commit) ```bash git reset --soft HEAD~1 ``` This undoes the last commit but leaves your changes in the staging area. ## Option 2: Keep changes **unstaged** (in working directory) ```bash git reset --mixed HEAD~1 # or simply: git reset HEAD~1 ``` This undoes the last commit and unstages the changes, but keeps them in your working directory. --- ## Quick Comparison | Command | Commit | Index | Working Dir | |---------|--------|-------|-------------| | `--soft` | ❌ | ✅ Changed | ✅ Changed | | `--mixed` | ❌ | ❌ Reset | ✅ Changed | --- ## Example ```bash # After committing something you want to redo: $ git reset --soft HEAD~1 # Your changes are back, staged and ready: $ git status # Changes to be committed: # modified: file.txt ``` **Note:** If you've already pushed to a remote, you'd need to force push (`git push --force-with-lease`) to update the remote repository.
rep 3: 127 words
# Undo Last Commit but Keep Changes The easiest way is to use `git reset` with the `--soft` flag: ```bash git reset --soft HEAD~1 ``` This will: - **Undo** the last commit - **Keep** your changes staged (ready to commit again) - Leave your working directory unchanged ## Alternative Options If you want the changes **unstaged** instead: ```bash git reset --mixed HEAD~1 # or simply: git reset HEAD~1 ``` This does the same thing but leaves the changes in your working directory without staging them. ## Comparison | Command | Commit | Staging Area | Working Dir | |---------|--------|--------------|------------| | `--soft` | Undo | Keep changes | Keep changes | | `--mixed` | Undo | Remove | Keep changes | | `--hard` | Undo | Remove | **Discard** ⚠️ | ⚠️ **Don't use `--hard`** if you want to keep the changes! After running `git reset --soft HEAD~1`, you can review your changes and commit them again when you're ready.
brief
rep 1: 27 words
```bash git reset --soft HEAD~1 ``` This moves HEAD back one commit while keeping changes staged. Remove `--soft` if you want changes unstaged instead: ```bash git reset HEAD~1 ```
rep 2: 43 words
```bash git reset --soft HEAD~1 ``` This moves the commit back to staging. The `--soft` flag keeps your changes intact. Your files will be ready to edit or re-commit. If you want the changes unstaged instead, use `--mixed` (the default): ```bash git reset HEAD~1 ```
rep 3: 31 words
```bash git reset --soft HEAD~1 ``` This moves the commit back and stages the changes. If you want them unstaged instead, use `--mixed` (or just omit the flag, as `--mixed` is default).

gpt-5.6-terra

plain
rep 1: 29 words
```bash git reset --soft HEAD~1 ``` This removes the last commit while keeping its changes **staged**. If you want to keep the changes but **unstage** them: ```bash git reset HEAD~1 ```
rep 2: 45 words
```bash git reset --soft HEAD~1 ``` This removes the last commit while keeping all its changes **staged**. If you want the changes kept but **unstaged** instead: ```bash git reset HEAD~1 ``` If the commit was already pushed, avoid rewriting shared history unless coordinated; consider `git revert` instead.
rep 3: 47 words
```bash git reset --soft HEAD~1 ``` This removes the last commit but keeps all its changes **staged**. If you want to keep the changes but **unstage** them: ```bash git reset HEAD~1 ``` If the commit was already pushed, avoid rewriting shared history unless coordinated; consider: ```bash git revert HEAD ```
brief
rep 1: 16 words
```bash git reset --soft HEAD~1 ``` Keeps changes staged. Use `git reset HEAD~1` to keep them unstaged.
rep 2: 16 words
```bash git reset --soft HEAD~1 ``` Keeps changes staged. Use `git reset HEAD~1` to keep them unstaged.
rep 3: 13 words
```bash git reset --soft HEAD~1 ``` Keeps changes staged. Use `--mixed` to unstage them.

claude-opus-5

plain
rep 1: 102 words
``` git reset --soft HEAD~1 ``` This moves HEAD back one commit while leaving your changes staged in the index. Variants depending on what you want: - `git reset --soft HEAD~1` — changes stay staged, ready to re-commit - `git reset HEAD~1` (mixed, the default) — changes stay in working tree but unstaged - `git reset --hard HEAD~1` — discards the changes entirely (careful) If you just want to fix the message or add a forgotten file, skip the reset: ``` git commit --amend ``` Note: if you already pushed the commit, undoing it rewrites history, so you'd need `git push --force-with-lease` — only do that if no one else has pulled it.
rep 2: 113 words
``` git reset --soft HEAD~1 ``` This moves HEAD back one commit while leaving your changes staged in the index and working tree. Variants: - `git reset HEAD~1` (mixed, the default) — undoes the commit and unstages the changes, but keeps them in your working tree. - `git reset --hard HEAD~1` — undoes the commit **and** discards the changes. Use with care. If you only want to edit the message or add a forgotten file to the same commit, use `git commit --amend` instead. Note: if you've already pushed the commit, rewriting history will require a force push (`git push --force-with-lease`), which disrupts anyone else who pulled it. In that case `git revert <commit>` is usually the safer choice.
rep 3: 115 words
``` git reset --soft HEAD~1 ``` This moves HEAD back one commit while leaving your changes staged in the index. Variations: - `git reset --soft HEAD~1` — changes stay staged (ready to re-commit) - `git reset HEAD~1` — changes stay in working directory, unstaged (`--mixed` is the default) - `git reset --hard HEAD~1` — **discards** the changes entirely If you only want to fix the commit message or add a forgotten file, amend instead: ``` git commit --amend ``` One caveat: if you already pushed the commit, rewriting history means you'd need `git push --force-with-lease`, which can disrupt anyone else working on that branch. In that case `git revert HEAD` is safer — it creates a new commit that undoes the changes rather than rewriting history.
brief
rep 1: 14 words
``` git reset --soft HEAD~1 ``` Changes stay staged. Use `--mixed` (default) to unstage them instead.
rep 2: 14 words
``` git reset --soft HEAD~1 ``` Changes stay staged. Use `--mixed` (default) to unstage them instead.
rep 3: 14 words
``` git reset --soft HEAD~1 ``` Changes stay staged. Use `--mixed` (default) to unstage them instead.

claude-opus-5-5

plain
rep 1: 114 words
Use `git reset` with the `--soft` or `--mixed` option: ```bash git reset --soft HEAD~1 ``` This undoes the last commit and leaves its changes **staged**, ready to recommit. ```bash git reset HEAD~1 ``` This is the default `--mixed` mode. It undoes the commit and leaves the changes in your working directory but **unstaged**. **Notes:** - **Don't use `--hard`.** It discards the changes entirely. - **If you've already pushed the commit,** resetting rewrites history, so you'd need `git push --force-with-lease`. On shared branches, it's safer to use `git revert HEAD`, which creates a new commit that undoes the old one. - **If you only want to fix the commit message or add a forgotten file,** use `git commit --amend` instead.
rep 2: 126 words
Use `git reset` with `HEAD~1`: ```bash git reset --soft HEAD~1 ``` This removes the last commit and leaves its changes **staged**, ready to recommit. If you'd rather have the changes **unstaged** (back in your working directory), use the default mixed mode: ```bash git reset HEAD~1 ``` **Notes:** - Don't use `--hard`. It discards the changes entirely. - If you've already pushed the commit, resetting rewrites history. Pushing again would then need `git push --force-with-lease`, which can disrupt collaborators. On a shared branch, `git revert HEAD` is safer: it creates a new commit that undoes the last one. However, revert doesn't keep the changes in your working tree. - If you just want to fix the last commit (add files or change the message), `git commit --amend` may be all you need.
rep 3: 149 words
Use a soft reset: ```bash git reset --soft HEAD~1 ``` This removes the last commit and leaves its changes **staged**, ready to recommit. **Variations:** - **Keep the changes but unstaged:** ```bash git reset HEAD~1 ``` (`--mixed` is the default.) - **Fix the commit instead of removing it**, for example to change the message or add a forgotten file: ```bash git add <files> git commit --amend ``` **If you've already pushed the commit:** resetting rewrites history, so you'd need `git push --force-with-lease` afterward. That can disrupt collaborators on a shared branch. In that case it's often safer to use: ```bash git revert HEAD ``` This creates a new commit that undoes the last one without rewriting history. Note that `git revert` doesn't keep the changes in your working tree. It undoes them. **Safety net:** If you reset by mistake, `git reflog` shows the previous commit hash, and you can restore it with `git reset --hard <hash>`.
brief
rep 1: 30 words
```bash git reset --soft HEAD~1 ``` Changes stay staged. To keep them unstaged instead: ```bash git reset HEAD~1 ``` If already pushed, use `git revert HEAD` instead. It won't rewrite shared history.
rep 2: 40 words
``` git reset --soft HEAD~1 ``` Changes stay staged. To unstage them too, use `git reset HEAD~1`. If you already pushed, use `git revert HEAD` instead. It adds a new commit that undoes the last one, which is safer for shared branches.
rep 3: 28 words
``` git reset --soft HEAD~1 ``` Changes stay staged. Use `git reset HEAD~1` (mixed) to keep them unstaged instead. If already pushed, use `git revert HEAD` instead of rewriting history.
float-sum: Why does 0.1 + 0.2 not equal 0.3 in JavaScript?

Reference answer: Numbers are binary floating point; 0.1 and 0.2 have no exact binary form, so the sum is rounded.

claude-haiku-4-5

plain
rep 1: 159 words
# The Floating-Point Precision Problem This is a classic issue caused by how JavaScript (and most programming languages) represent decimal numbers in binary format using the IEEE 754 standard. ## The Problem Decimal numbers like `0.1` and `0.2` **cannot be represented exactly** in binary floating-point format. They become infinite repeating decimals in binary, so they're approximated: ```javascript 0.1 + 0.2 === 0.3 // false 0.1 + 0.2 // 0.30000000000000004 ``` ## Why This Happens - `0.1` in binary is actually: `0.0001100110011...` (repeating) - `0.2` in binary is actually: `0.0011001100110...` (repeating) - These get rounded to the nearest representable value - When added together, the rounding errors compound ## Solutions **For comparisons, use a tolerance:** ```javascript const epsilon = Number.EPSILON; Math.abs(0.1 + 0.2 - 0.3) < epsilon // true ``` **For financial calculations, use integers (cents instead of dollars):** ```javascript (10 + 20) / 100 === 0.30 // true (working with cents) ``` **Or use a decimal library:** ```javascript // Using a library like Decimal.js or Big.js new Decimal('0.1').plus('0.2') // 0.3 ``` This isn't a JavaScript bug—it's a fundamental limitation of binary floating-point representation shared by most languages.
rep 2: 163 words
# The Classic JavaScript Floating-Point Issue This is a **binary representation problem**, not a JavaScript bug. Here's what happens: ## The Problem ```javascript 0.1 + 0.2 === 0.3 // false 0.1 + 0.2 // 0.30000000000000004 ``` ## Why? JavaScript uses **IEEE 754 double-precision floating-point** format, which represents numbers in binary. Decimals like 0.1 and 0.2 **cannot be represented exactly** in binary: ``` 0.1 in binary ≈ 0.0001100110011001100... (repeating) 0.2 in binary ≈ 0.0011001100110011001... (repeating) ``` These are rounded to the nearest representable value, introducing tiny errors that accumulate when added. ## Solutions ### 1. **Use `toFixed()` for comparisons** ```javascript (0.1 + 0.2).toFixed(1) === '0.3' // true ``` ### 2. **Check if values are "close enough"** (epsilon comparison) ```javascript const epsilon = Number.EPSILON; Math.abs(0.1 + 0.2 - 0.3) < epsilon // true ``` ### 3. **Work with integers when possible** ```javascript // Instead of: 0.1 + 0.2 // Do: (10 + 20) / 100 (10 + 20) / 100 // 0.3 ✓ ``` ### 4. **Use libraries for decimal arithmetic** ```javascript // decimal.js, big.js, or similar new Decimal(0.1).plus(0.2).equals(0.3) // true ``` This issue exists in **all languages** using IEEE 754 (Python, Java, C#, etc.), so it's a fundamental computer science concept, not a JavaScript quirk!
rep 3: 167 words
# The 0.1 + 0.2 Problem in JavaScript This is a **floating-point precision issue**, not a JavaScript bug. Here's what happens: ```javascript 0.1 + 0.2 // Returns: 0.30000000000000004 0.1 + 0.2 === 0.3 // Returns: false ``` ## Why? JavaScript uses **IEEE 754 double-precision binary floating-point** format. The problem: 1. **0.1 and 0.2 can't be represented exactly in binary** - 0.1 in binary is a repeating decimal (like 1/3 = 0.333... in decimal) - The number gets rounded to the nearest representable value - This introduces tiny rounding errors 2. **These errors accumulate when you add them** - Rounded 0.1 + Rounded 0.2 ≠ Exact 0.3 3. **The result contains a representation artifact:** ``` 0.30000000000000004 ``` ## Solutions **1. Use a small tolerance (epsilon comparison):** ```javascript Math.abs(0.1 + 0.2 - 0.3) < Number.EPSILON // true ``` **2. Round to a fixed number of decimals:** ```javascript parseFloat((0.1 + 0.2).toFixed(2)) // 0.3 ``` **3. Use integer arithmetic (multiply by 100):** ```javascript (10 + 20) / 100 // 0.3 ``` **4. Use a decimal library:** ```javascript // Using decimal.js or similar library for precise math ``` This isn't unique to JavaScript—it affects most programming languages that use binary floating-point (Python, Java, C++, etc.).
brief
rep 1: 34 words
# Floating-Point Precision `0.1` and `0.2` cannot be exactly represented in binary (IEEE 754). They're stored as approximations, so their sum accumulates rounding error: `0.30000000000000004`. This affects all languages with binary floats, not just JavaScript.
rep 2: 23 words
Binary floating-point numbers (IEEE 754) can't represent 0.1 and 0.2 exactly. The closest approximations, when added, produce rounding errors: `0.30000000000000004` instead of `0.3`.
rep 3: 50 words
**Binary floating-point limitation.** Decimals like 0.1, 0.2, and 0.3 can't be exactly represented in binary (IEEE 754 standard). They become repeating decimals that get rounded. ```javascript 0.1 + 0.2 // 0.30000000000000004 ``` The tiny errors from rounding each number compound when added together. **Not a JavaScript bug—it's how computers store decimals in memory.**

gpt-5.6-terra

plain
rep 1: 81 words
JavaScript uses IEEE 754 binary floating-point numbers. Values like `0.1` and `0.2` cannot be represented exactly in binary, so they are stored as tiny approximations. ```js 0.1 + 0.2 // 0.30000000000000004 ``` The approximations add up to a value slightly different from the approximation for `0.3`. For comparisons, use a tolerance: ```js const nearlyEqual = (a, b, epsilon = Number.EPSILON) => Math.abs(a - b) < epsilon; nearlyEqual(0.1 + 0.2, 0.3); // true ``` For currency or exact decimal work, store minor units as integers (e.g. cents) or use a decimal arithmetic library.
rep 2: 88 words
JavaScript uses IEEE 754 binary floating-point numbers. Values like `0.1` and `0.2` cannot be represented exactly in binary, so they are stored as tiny approximations. ```js 0.1 + 0.2 // 0.30000000000000004 0.1 + 0.2 === 0.3 // false ``` This is not JavaScript-specific; it occurs in most languages using binary floating point. For comparisons, use a tolerance: ```js const nearlyEqual = (a, b, epsilon = Number.EPSILON) => Math.abs(a - b) < epsilon; nearlyEqual(0.1 + 0.2, 0.3); // true ``` For exact decimal quantities such as money, store the smallest unit as an integer (for example, cents) or use a decimal arithmetic library.
rep 3: 73 words
JavaScript uses IEEE 754 binary floating-point numbers. Decimal fractions like `0.1` and `0.2` cannot be represented exactly in binary, so they are stored as tiny approximations. Their approximations add up to: ```js 0.1 + 0.2 // 0.30000000000000004 ``` rather than the approximation used for `0.3`. For comparisons, allow a small tolerance: ```js Math.abs((0.1 + 0.2) - 0.3) < Number.EPSILON // true ``` For currency or exact decimal work, prefer storing integer minor units (e.g. cents) or use a decimal arithmetic library.
brief
rep 1: 28 words
JavaScript uses binary floating-point. `0.1` and `0.2` can’t be represented exactly, so rounding yields: ```js 0.1 + 0.2 // 0.30000000000000004 ``` Use tolerance checks or decimal libraries for exact decimal math.
rep 2: 28 words
JavaScript uses binary floating-point. `0.1` and `0.2` can’t be represented exactly, so rounding yields: ```js 0.1 + 0.2 // 0.30000000000000004 ``` Use rounding or integer minor units for exact decimal money.
rep 3: 18 words
JavaScript uses binary floating-point. `0.1` and `0.2` can’t be represented exactly, so rounding yields: ```js 0.1 + 0.2 // 0.30000000000000004 ```

claude-opus-5

plain
rep 1: 302 words
Because JavaScript numbers are IEEE 754 double-precision binary floats, and 0.1 and 0.2 can't be represented exactly in binary. **The core issue:** In base 10, 1/3 is a repeating decimal (0.333...) that you must truncate. In base 2, anything whose denominator isn't a power of 2 repeats — and 1/10 is one of those. So 0.1 becomes an infinitely repeating binary fraction that gets rounded to 53 bits of precision. **What actually happens:** ``` 0.1 → 0.1000000000000000055511151231257827021181583404541015625 0.2 → 0.2000000000000000111022302462515654042363166809082031250 sum → 0.3000000000000000444089209850062616169452667236328125 ``` That sum isn't the closest double to 0.3, so it prints as `0.30000000000000004`. Meanwhile the literal `0.3` rounds to `0.29999999999999998889776975374843...` — a different value entirely. Hence `false`. Note that JS prints the *shortest* string that round-trips back to the same double, which is why `0.1` displays as `0.1` even though it isn't exactly that. **Why 0.1 + 0.2 but not 0.1 + 0.3?** Some errors happen to cancel. `0.1 + 0.3 === 0.4` is `true`, and `0.5 + 0.25 === 0.75` is always true since those are exact binary fractions. The failures are unpredictable, which is why you can't just memorize the bad cases. **What to do about it:** *Comparisons* — use a tolerance: ```js Math.abs(a - b) < Number.EPSILON * Math.max(Math.abs(a), Math.abs(b)) ``` The naive `< Number.EPSILON` only works for values near 1.0; scaling by magnitude handles large numbers. For values near zero you'll want an absolute tolerance instead. *Money* — don't use floats. Store integer cents (`1999` not `19.99`), or use `BigInt`, or a decimal library like decimal.js. Note that `toFixed(2)` is a display fix, not a storage fix, and it has its own rounding quirks (`(1.005).toFixed(2)` gives `"1.00"`). *Accumulating sums* — errors compound over many additions. Kahan summation or just summing integers helps. This isn't a JavaScript bug — Python, Java, C, and Go all do the same thing. JS is just more visible about it because it has a single `Number` type and REPLs are everywhere.
rep 2: 210 words
Because JavaScript numbers are IEEE 754 double-precision binary floating point, and neither 0.1 nor 0.2 can be represented exactly in binary. **The core issue:** In base 10, 1/3 can't be written exactly (0.333...). In base 2, 1/10 has the same problem — it's an infinitely repeating fraction. So `0.1` is actually stored as the nearest representable double: ``` 0.1 → 0.1000000000000000055511151231257827... 0.2 → 0.2000000000000000111022302462515654... ``` Adding those gives something slightly above 0.3, and the nearest double to that sum is *not* the same as the nearest double to `0.3`: ```js 0.1 + 0.2 // 0.30000000000000004 0.3 // 0.29999999999999998889776975374843... 0.1 + 0.2 === 0.3 // false ``` The two differ by one "unit in the last place" (~5.5e-17). **How to deal with it:** Compare with a tolerance rather than exact equality: ```js const eq = (a, b, eps = Number.EPSILON) => Math.abs(a - b) < eps; eq(0.1 + 0.2, 0.3); // true ``` For display, round explicitly: ```js (0.1 + 0.2).toFixed(2); // "0.30" ``` For money or anything where exactness matters, use integers (cents instead of dollars) or a decimal library. `BigInt` works for whole numbers; libraries like `decimal.js` handle arbitrary-precision decimals. Worth noting this isn't a JavaScript quirk — Python, Java, C, and Ruby all do the same thing. JS is just more visible about it because it has a single `Number` type and prints the shortest string that round-trips to the stored value.
rep 3: 262 words
Because JavaScript numbers are IEEE 754 double-precision binary floats, and 0.1 and 0.2 have no exact representation in binary. **The core issue:** In base 10, 1/3 is 0.3333... — infinitely repeating. In base 2, 1/10 has the same problem: 0.0001100110011... repeating forever. Since a double only has 53 bits of significand, the value gets rounded. So what you actually store is: ``` 0.1 → 0.1000000000000000055511151231257827021181583404541015625 0.2 → 0.2000000000000000111022302462515654042363166809082031250 ``` Add those and the exact sum rounds to the nearest representable double, which happens to be `0.30000000000000004` — a different double than the one you get from writing the literal `0.3`. ```js 0.1 + 0.2 === 0.3 // false 0.1 + 0.2 // 0.30000000000000004 (0.1 + 0.2).toFixed(20) // "0.30000000000000004441" (0.3).toFixed(20) // "0.29999999999999998890" ``` Note that `0.1 + 0.2` prints as `0.30000000000000004` rather than `0.1`-style clean output because JS prints the *shortest* string that round-trips to the same double — and for this particular value, that requires 17 digits. **How to deal with it:** *Compare with a tolerance:* ```js const nearlyEqual = (a, b, eps = Number.EPSILON) => Math.abs(a - b) < eps * Math.max(1, Math.abs(a), Math.abs(b)); ``` *For money, use integers* — store cents, not dollars: ```js const total = 10 + 20; // 30 cents, exact ``` *For arbitrary precision, use `BigInt` or a decimal library* like decimal.js or big.js. There's also a TC39 proposal for a native `Decimal` type, though it's still in flux. *Avoid `toFixed` for rounding-then-comparing* — it has its own quirks (`(1.005).toFixed(2)` is `"1.00"`, because 1.005 is actually stored slightly below 1.005). This isn't a JavaScript bug — Python, Java, C, and Go all give the same answer. It's just that JS surfaces it more often since it has no built-in integer or decimal type to reach for instead.
brief
rep 1: 38 words
Floating point (IEEE 754 binary64). 0.1 and 0.2 can't be represented exactly in binary — like 1/3 in decimal. The tiny errors add up to 0.30000000000000004. Fix: compare with a tolerance (`Math.abs(a-b) < Number.EPSILON`) or use integers/decimal libraries for money.
rep 2: 31 words
Binary floating point (IEEE 754). 0.1 and 0.2 can't be represented exactly in base 2, so their sum lands slightly off: 0.30000000000000004. Fix: compare with a tolerance, or round — `(0.1 + 0.2).toFixed(2)`.
rep 3: 34 words
Floating-point (IEEE 754) binary can't represent 0.1 or 0.2 exactly — like 1/3 in decimal. The tiny rounding errors sum to 0.30000000000000004. Fix: compare with a tolerance (`Math.abs(a-b) < Number.EPSILON`) or use integers/decimal libraries for money.

claude-opus-5-5

plain
rep 1: 317 words
In JavaScript, `0.1 + 0.2` gives `0.30000000000000004`, not `0.3`. This isn't a JavaScript bug. It comes from how computers store decimal numbers in binary. ## The root cause: binary floating-point JavaScript stores all numbers as **IEEE 754 double-precision floats** (64 bits). These represent numbers in **base 2**, and many simple decimal fractions have no exact finite representation in binary. It's the same problem as writing 1/3 in decimal: `0.333333...` goes on forever. In binary, `0.1` goes on forever too: ``` 0.1 (decimal) = 0.0001100110011001100110011... (binary, repeating) ``` With only 52 bits for the fraction, the value must be rounded. So `0.1` is actually stored as: ``` 0.1000000000000000055511151231257827021181583404541015625 ``` and `0.2` as: ``` 0.200000000000000011102230246251565404236316680908203125 ``` ## Why the error shows up When you add them, the small errors combine, and the result rounds to the nearest representable double. That double is **not** the same one closest to `0.3`: ```js 0.1 + 0.2 // 0.30000000000000004 0.3 // stored as 0.299999999999999988897769753748... 0.1 + 0.2 === 0.3 // false ``` The two values land on neighboring doubles, so equality fails. Some other sums, like `0.1 + 0.7`, also fail, while others happen to round to the expected value. ## How to handle it **1. Compare with a tolerance (epsilon):** ```js function nearlyEqual(a, b, epsilon = Number.EPSILON) { return Math.abs(a - b) < epsilon; } nearlyEqual(0.1 + 0.2, 0.3); // true ``` `Number.EPSILON` (~2.22e-16) works for values near 1. For larger magnitudes, use a relative tolerance. **2. Round for display:** ```js (0.1 + 0.2).toFixed(2); // "0.30" (string) Number((0.1 + 0.2).toFixed(10)); // 0.3 ``` **3. Use integers for money.** Work in cents instead of dollars: ```js const total = 10 + 20; // cents console.log(total / 100); // 0.3 ``` **4. Use a decimal library** for exact decimal math, such as `decimal.js`, `big.js`, or `bignumber.js`. ## Key takeaway This affects nearly every language that uses IEEE 754 floats, including Python, Java, C, and C++. Floats are fast and precise enough for most scientific work, but they can't exactly represent most decimal fractions. So never use `===` to compare the results of float arithmetic, and don't use floats for exact decimal quantities like currency.
rep 2: 316 words
In JavaScript, `0.1 + 0.2` gives `0.30000000000000004`, not `0.3`. This isn't a JavaScript bug. It comes from how computers store decimal numbers in binary. ## The root cause: binary floating point JavaScript stores all numbers as **64-bit IEEE 754 double-precision floats**. They are stored in **base 2 (binary)**, not base 10. Some fractions can't be represented exactly in a given base: - In base 10, `1/3` = `0.3333...` repeats forever. - In base 2, `1/10` (0.1) = `0.0001100110011001100...` also repeats forever. Since there are only 52 bits for the fraction, the value gets **rounded** to the nearest representable number. So what's stored for `0.1` is actually: ``` 0.1000000000000000055511151231257827021181583404541015625 ``` And `0.2` is stored as: ``` 0.200000000000000011102230246251565404236316680908203125 ``` When you add them, the small errors combine. The result rounds to a double that is slightly larger than the double closest to `0.3`: ```js 0.1 + 0.2 // 0.30000000000000004 0.1 + 0.2 === 0.3 // false ``` ## It's not just JavaScript Python, Java, C, C#, Ruby, and most other languages that use IEEE 754 doubles behave the same way. (See [0.30000000000000004.com](https://0.30000000000000004.com).) ## How to handle it **1. Compare with a tolerance (epsilon):** ```js function nearlyEqual(a, b, epsilon = Number.EPSILON) { return Math.abs(a - b) < epsilon; } nearlyEqual(0.1 + 0.2, 0.3); // true ``` For larger magnitudes, use a relative tolerance, such as `epsilon * Math.max(Math.abs(a), Math.abs(b))`. **2. Round for display:** ```js (0.1 + 0.2).toFixed(2); // "0.30" (string) Number((0.1 + 0.2).toFixed(10)); // 0.3 ``` **3. Use integers for money.** Work in cents instead of dollars: ```js const total = 10 + 20; // cents console.log(total / 100); // 0.3 ``` **4. Use a decimal library** for precise arithmetic, such as `decimal.js`, `big.js`, or `bignumber.js`: ```js new Decimal(0.1).plus(0.2).equals(0.3); // true ``` **5. Use `BigInt`** when you need exact integers beyond `Number.MAX_SAFE_INTEGER`. It only handles integers, not fractions. ## Summary `0.1` and `0.2` can't be stored exactly in binary, so each is slightly off. Their sum lands on a slightly different value than the stored `0.3`. For equality checks, compare against a tolerance instead of using `===`. For money or anything that needs exact decimals, use integers or a decimal library.
rep 3: 325 words
In JavaScript, `0.1 + 0.2` evaluates to `0.30000000000000004`, not `0.3`. This isn't a JavaScript bug. It comes from how nearly all modern languages store decimal numbers. ## The root cause: binary floating point JavaScript stores every number as an **IEEE 754 double-precision (64-bit) floating-point** value. These numbers are stored in **binary (base 2)**, and many simple decimal fractions have no exact binary representation. It's the same problem as writing 1/3 in decimal: `0.3333333...` never ends, so any finite version is slightly off. In binary, `0.1` is a repeating fraction: ``` 0.1 (decimal) = 0.0001100110011001100110011... (binary, repeating forever) ``` A double has only 52 bits for the fraction (plus 1 implicit bit), so the value gets **rounded** to the nearest representable number. The stored values are actually: ``` 0.1 → 0.1000000000000000055511151231257827... 0.2 → 0.2000000000000000111022302462515654... 0.3 → 0.2999999999999999888977697537484345... ``` ## Why the sum misses When you add the stored approximations of `0.1` and `0.2`, the tiny errors add up, and the result is rounded to the nearest double. That nearest double is **not** the same one used for the literal `0.3`: ```js 0.1 + 0.2 // 0.30000000000000004 0.1 + 0.2 === 0.3 // false ``` The two values differ by one "step" (ULP) in the last bit, so strict equality fails. ## How to handle it **1. Compare with a tolerance (epsilon):** ```js function nearlyEqual(a, b, epsilon = Number.EPSILON) { return Math.abs(a - b) < epsilon; } nearlyEqual(0.1 + 0.2, 0.3); // true ``` `Number.EPSILON` (~2.22e-16) suits numbers near 1. For larger magnitudes, use a relative tolerance: `Math.abs(a - b) < epsilon * Math.max(Math.abs(a), Math.abs(b))`. **2. Round for display:** ```js (0.1 + 0.2).toFixed(2); // "0.30" (string) Number((0.1 + 0.2).toFixed(10)); // 0.3 ``` **3. Use integers for money:** store cents instead of dollars. ```js const total = 10 + 20; // cents total / 100; // 0.3 ``` **4. Use a decimal library** for precise arithmetic, such as `decimal.js`, `big.js`, or `bignumber.js`. ## Key takeaway Floating-point numbers are **approximations**. Never use `===` to compare the results of floating-point arithmetic. Use a tolerance, or avoid fractional math entirely when exactness matters, as with currency. The same behavior occurs in Python, Java, C, C++, and any other language using IEEE 754 doubles.
brief
rep 1: 59 words
JavaScript numbers are **IEEE 754 double-precision binary floats**. 0.1 and 0.2 can't be represented exactly in binary (like 1/3 in decimal), so each is stored as a tiny approximation. Their rounding errors add up: ```js 0.1 + 0.2 // 0.30000000000000004 ``` **Fix:** compare with a tolerance: ```js Math.abs(0.1 + 0.2 - 0.3) < Number.EPSILON // true ``` Or, for money, use integers (cents) or a decimal library.
rep 2: 58 words
JavaScript numbers are IEEE 754 binary floating-point (64-bit). Like 1/3 in decimal, 0.1 and 0.2 **can't be represented exactly in binary**, so each is stored as the nearest approximation. Their rounding errors add up: ```js 0.1 + 0.2 // 0.30000000000000004 ``` **Fix:** compare within a tolerance: ```js Math.abs(0.1 + 0.2 - 0.3) < Number.EPSILON // true ``` For money, use integers (cents) or a decimal library.
rep 3: 69 words
JavaScript stores numbers as **IEEE 754 binary floating-point** (64-bit doubles). Values like 0.1 and 0.2 can't be represented exactly in binary, just as 1/3 can't be written exactly in decimal. Each is stored as the nearest representable value, and the tiny rounding errors add up: ```js 0.1 + 0.2 // 0.30000000000000004 ``` **Fix:** compare with a tolerance: ```js Math.abs(0.1 + 0.2 - 0.3) < Number.EPSILON // true ``` For money, use integers (cents) or a decimal library.
http-429: Which HTTP status code means that the client sent too many requests?

Reference answer: 429

claude-haiku-4-5

plain
rep 1: 71 words
The HTTP status code for "too many requests" is **429 Too Many Requests**. This status code indicates that the client has sent too many requests in a given time period and is being rate-limited. It was introduced in RFC 6585 and is commonly used for: - Rate limiting enforcement - Quota exceeded scenarios - DDoS protection mechanisms The response may also include a `Retry-After` header to indicate when the client can retry the request.
rep 2: 94 words
# HTTP 429 - Too Many Requests The HTTP status code **429** means "Too Many Requests." This status code indicates that the client has sent too many requests to the server in a given amount of time, typically triggered by rate limiting policies. ## Key details: - **Definition**: Defined in RFC 6585 - **Use case**: Rate limiting and throttling - **Optional header**: The response may include a `Retry-After` header indicating how long the client should wait before making another request ## Example: ``` HTTP/1.1 429 Too Many Requests Retry-After: 60 Content-Type: application/json { "error": "Rate limit exceeded. Please try again in 60 seconds." } ```
rep 3: 111 words
# HTTP 429 - Too Many Requests The HTTP status code **429 Too Many Requests** indicates that the client has sent too many requests in a given amount of time (rate limiting). ## Key Details: - **Status Code**: 429 - **Defined in**: RFC 6585 - **Use Case**: Server-side rate limiting to prevent abuse - **Common Header**: Often accompanied by a `Retry-After` header that tells the client when it can make the next request ## Example Response: ``` HTTP/1.1 429 Too Many Requests Retry-After: 60 { "error": "Too Many Requests", "message": "You have exceeded the rate limit. Please try again later." } ``` This status code is commonly used by APIs, web services, and web servers to protect against abuse and maintain service stability.
brief
rep 1: 21 words
**429 Too Many Requests** This status code indicates rate limiting - the client has sent too many requests in a given timeframe.
rep 2: 22 words
**429 Too Many Requests** This status code indicates the client has sent too many requests in a given time period (rate limiting).
rep 3: 22 words
**429 (Too Many Requests)** This indicates the client has sent too many requests in a given timeframe, typically used for rate limiting.

gpt-5.6-terra

plain
rep 1: 5 words
HTTP **429 Too Many Requests**.
rep 2: 5 words
HTTP **429 Too Many Requests**.
rep 3: 5 words
HTTP **429 Too Many Requests**.
brief
rep 1: 4 words
429 Too Many Requests
rep 2: 4 words
429 Too Many Requests
rep 3: 4 words
429 Too Many Requests

claude-opus-5

plain
rep 1: 54 words
**429 Too Many Requests** It indicates the client has sent too many requests in a given time period — i.e., it has hit a rate limit. Defined in RFC 6585. Servers commonly pair it with a `Retry-After` header telling the client how long to wait (either in seconds or as an HTTP date) before retrying.
rep 2: 33 words
**429 Too Many Requests** It's defined in RFC 6585 and indicates the client has exceeded a rate limit. Responses often include a `Retry-After` header telling the client how long to wait before retrying.
rep 3: 33 words
**429 Too Many Requests** It's defined in RFC 6585 and indicates the client has exceeded a rate limit. Responses often include a `Retry-After` header telling the client how long to wait before retrying.
brief
rep 1: 4 words
429 Too Many Requests
rep 2: 4 words
429 Too Many Requests
rep 3: 4 words
429 Too Many Requests

claude-opus-5-5

plain
rep 1: 64 words
**HTTP 429 Too Many Requests** means the client has sent too many requests in a given amount of time, which is known as rate limiting. It's defined in RFC 6585. The server may include a `Retry-After` header saying how long the client should wait before retrying, either as a number of seconds or as an HTTP date: ``` HTTP/1.1 429 Too Many Requests Retry-After: 60 ```
rep 2: 108 words
The status code is **429 Too Many Requests**. The server returns it when a client has sent too many requests in a given period, which is usually how **rate limiting** is enforced. - **Defined in:** RFC 6585 - **Common header:** The response often includes a `Retry-After` header. It tells the client how long to wait before trying again, either as a number of seconds or as an HTTP date. Example response: ``` HTTP/1.1 429 Too Many Requests Retry-After: 60 Content-Type: application/json {"error": "Rate limit exceeded. Try again in 60 seconds."} ``` A client that receives a 429 should back off. Good ways to do that are honoring `Retry-After` or using exponential backoff.
rep 3: 53 words
**HTTP 429 Too Many Requests** means the client has sent too many requests in a given amount of time. This is rate limiting, defined in RFC 6585. The server may include a `Retry-After` header telling the client how long to wait before trying again, for example: ``` HTTP/1.1 429 Too Many Requests Retry-After: 60 ```
brief
rep 1: 4 words
**429 Too Many Requests**
rep 2: 4 words
**429 Too Many Requests**
rep 3: 4 words
**429 Too Many Requests**
docker-running: How do I list the running Docker containers?

Reference answer: docker ps

claude-haiku-4-5

plain
rep 1: 130 words
# List Running Docker Containers To list running Docker containers, use: ```bash docker ps ``` ## Useful Variations **List all containers (including stopped ones):** ```bash docker ps -a ``` **Show only container IDs:** ```bash docker ps -q ``` **Show all containers with only IDs (stopped included):** ```bash docker ps -aq ``` **Display additional details with custom format:** ```bash docker ps --format "table {{.ID}}\t{{.Image}}\t{{.Status}}\t{{.Names}}" ``` **Filter containers by status:** ```bash docker ps -a --filter "status=running" docker ps -a --filter "status=exited" ``` **Filter by image name:** ```bash docker ps --filter "ancestor=nginx" ``` ## Common Output Columns - **CONTAINER ID** - Unique identifier - **IMAGE** - The image used to create the container - **COMMAND** - Command run on startup - **CREATED** - When the container was created - **STATUS** - Current status (Up, Exited, etc.) - **PORTS** - Mapped ports - **NAMES** - Container names Would you like help with any specific Docker container management tasks?
rep 2: 135 words
# Listing Running Docker Containers Here are the most common ways to list Docker containers: ## List Running Containers Only ```bash docker ps ``` This shows only containers that are currently running. ## List All Containers (Running and Stopped) ```bash docker ps -a ``` ## Useful Flags | Flag | Description | |------|-------------| | `-a, --all` | Show all containers (including stopped ones) | | `-q, --quiet` | Only display container IDs | | `-s, --size` | Display total file sizes | | `--format` | Pretty-print containers using a Go template | | `-l, --latest` | Show the latest created container | | `-n` | Show last n containers | ## Examples ```bash # Show last 5 containers docker ps -n 5 # Show only container IDs docker ps -q # Show all containers with custom format docker ps -a --format "table {{.ID}}\t{{.Image}}\t{{.Status}}" # Show containers with their sizes docker ps -a -s ``` The default `docker ps` output includes: Container ID, Image, Command, Created, Status, Ports, and Names.
rep 3: 103 words
# List Running Docker Containers To list running Docker containers, use: ```bash docker ps ``` ## Useful Variations | Command | Description | |---------|-------------| | `docker ps` | List only running containers | | `docker ps -a` | List all containers (running and stopped) | | `docker ps -q` | List only container IDs | | `docker ps --format "table {{.Names}}\t{{.Status}}"` | Custom format output | ## Example Output ``` CONTAINER ID IMAGE COMMAND STATUS PORTS NAMES a1b2c3d4e5f6 nginx "nginx -g daemon" Up 2 hours 80/tcp webserver f6e5d4c3b2a1 postgres "postgres" Up 1 hour 5432/tcp database ``` ## Common Options - `-l` - Show the latest container created - `-n [NUMBER]` - Show the last n containers - `--no-trunc` - Don't truncate output Would you like help with any specific Docker container operations?
brief
rep 1: 18 words
```bash docker ps ``` This lists running containers. Add `-a` flag to include stopped containers: ```bash docker ps -a ```
rep 2: 18 words
Use: ```bash docker ps ``` This lists running containers. Add `-a` to include stopped containers: ```bash docker ps -a ```
rep 3: 16 words
```bash docker ps ``` This lists running containers. Add `-a` to see all containers (including stopped ones).

gpt-5.6-terra

plain
rep 1: 12 words
```bash docker ps ``` To include stopped containers too: ```bash docker ps -a ```
rep 2: 12 words
```bash docker ps ``` To include stopped containers too: ```bash docker ps -a ```
rep 3: 12 words
```bash docker ps ``` To include stopped containers too: ```bash docker ps -a ```
brief
rep 1: 3 words
```bash docker ps ```
rep 2: 3 words
```bash docker ps ```
rep 3: 2 words
`docker ps`

claude-opus-5

plain
rep 1: 10 words
`docker ps` To include stopped containers, use `docker ps -a`.
rep 2: 10 words
`docker ps` To include stopped containers, use `docker ps -a`.
rep 3: 10 words
`docker ps` To include stopped containers, use `docker ps -a`.
brief
rep 1: 8 words
`docker ps` (add `-a` for stopped ones too)
rep 2: 8 words
`docker ps` (add `-a` for stopped ones too)
rep 3: 8 words
`docker ps` (add `-a` for stopped ones too)

claude-opus-5-5

plain
rep 1: 96 words
Use: ```bash docker ps ``` This shows running containers with their ID, image, command, creation time, status, ports, and name. **Common variations:** ```bash docker ps -a # All containers, including stopped ones docker ps -q # Only container IDs (handy for scripting) docker ps -l # The most recently created container docker ps -s # Include disk size ``` **Filtering and formatting:** ```bash docker ps --filter "name=web" # Filter by name docker ps --filter "status=exited" # Filter by status (use with -a) docker ps --format "table {{.Names}}\t{{.Status}}\t{{.Ports}}" # Custom columns ``` `docker container ls` is the newer equivalent of `docker ps` and takes the same flags.
rep 2: 110 words
Use `docker ps`: ```bash docker ps ``` This shows each running container's ID, image, command, creation time, status, ports, and name. **Useful variations:** ```bash docker ps -a # All containers, including stopped ones docker ps -q # Only container IDs (handy for scripting) docker ps -l # The most recently created container docker ps -s # Include disk size docker ps --no-trunc # Don't truncate output # Filter docker ps --filter "status=exited" docker ps --filter "name=web" docker ps --filter "ancestor=nginx" # Custom output format docker ps --format "table {{.Names}}\t{{.Status}}\t{{.Ports}}" ``` `docker container ls` is the newer equivalent and does exactly the same thing. If you're using Docker Compose, `docker compose ps` lists only the containers for the current project.
rep 3: 101 words
Use `docker ps`: ```bash docker ps ``` This shows each running container's ID, image, command, creation time, status, ports, and name. **Useful variations:** ```bash docker ps -a # Include stopped containers docker ps -q # Show only container IDs docker ps -l # Show the most recently created container docker ps --no-trunc # Don't truncate output docker ps -s # Include container sizes ``` **Filtering:** ```bash docker ps --filter "name=web" # By name docker ps --filter "status=exited" # By status (use with -a) docker ps --filter "ancestor=nginx" # By image ``` **Custom output format:** ```bash docker ps --format "table {{.Names}}\t{{.Image}}\t{{.Status}}" ``` `docker container ls` is the newer equivalent and takes the same flags.
brief
rep 1: 8 words
``` docker ps ``` Add `-a` to include stopped containers.
rep 2: 9 words
```bash docker ps ``` Add `-a` to include stopped containers.
rep 3: 8 words
``` docker ps ``` Add `-a` to include stopped containers.
tcp-vs-udp: What is the difference between TCP and UDP?

Reference answer: TCP is connection-oriented and reliable; UDP is connectionless and unreliable.

claude-haiku-4-5

plain
rep 1: 187 words
# TCP vs UDP Here are the main differences between these two transport layer protocols: ## **TCP (Transmission Control Protocol)** - **Connection-oriented**: Establishes a connection (3-way handshake) before data transfer - **Reliable**: Guarantees all packets arrive in order and without errors - **Ordered delivery**: Maintains packet sequence - **Flow control**: Manages transmission speed to prevent overwhelming the receiver - **Error checking**: Detects and retransmits lost packets - **Slower**: More overhead due to reliability mechanisms - **Larger header**: 20-60 bytes - **Use cases**: Email, web browsing (HTTPS), file transfer, instant messaging ## **UDP (User Datagram Protocol)** - **Connectionless**: No connection setup; data is sent immediately - **Unreliable**: No guarantee packets arrive or arrive in order - **No ordering**: Packets may arrive out of sequence - **No flow control**: Sends data at application's pace - **Minimal error checking**: Basic checksum only; no retransmission - **Faster**: Less overhead and latency - **Smaller header**: 8 bytes - **Use cases**: Video/audio streaming, online gaming, DNS queries, VoIP, live broadcasts ## **Quick Comparison Table** | Feature | TCP | UDP | |---------|-----|-----| | Connection | Required | Not required | | Reliability | Guaranteed | Not guaranteed | | Speed | Slower | Faster | | Ordering | Ordered | Unordered | | Use Case | Accuracy critical | Speed critical | **Choose TCP** when data integrity is essential. **Choose UDP** when speed matters more than perfect delivery.
rep 2: 168 words
# TCP vs UDP Here are the key differences between these two transport layer protocols: ## **TCP (Transmission Control Protocol)** - **Connection-oriented**: Establishes a connection before sending data (3-way handshake) - **Reliable**: Guarantees all data reaches the destination in the correct order - **Error checking**: Extensive error detection and correction - **Flow control**: Manages data transmission rate - **Slower**: Additional overhead from reliability features - **Use cases**: Email, web browsing (HTTP/HTTPS), file transfer (FTP), remote access (SSH) ## **UDP (User Datagram Protocol)** - **Connectionless**: Sends data immediately without establishing a connection - **Unreliable**: No guarantee data arrives or arrives in order - **Minimal error checking**: Basic checksum only - **No flow control**: Sends data at application's pace - **Faster**: Lower latency due to minimal overhead - **Use cases**: Video streaming, online gaming, VoIP, DNS queries, live broadcasts ## **Quick Comparison Table** | Feature | TCP | UDP | |---------|-----|-----| | Connection | Required | Not required | | Reliability | Guaranteed | Best-effort | | Speed | Slower | Faster | | Ordering | Guaranteed | Not guaranteed | | Overhead | High | Low | ## **When to Use** - **Choose TCP** when data accuracy is critical - **Choose UDP** when speed matters more than perfect delivery (some packet loss acceptable)
rep 3: 150 words
# TCP vs UDP Here are the key differences between these two network protocols: ## **Connection** - **TCP**: Connection-oriented (establishes connection first via handshake) - **UDP**: Connectionless (sends data immediately without setup) ## **Reliability** - **TCP**: Reliable delivery - ensures all packets arrive correctly and in order - **UDP**: Unreliable - no guarantee packets arrive or maintain sequence ## **Speed** - **TCP**: Slower due to connection establishment and error checking - **UDP**: Faster with minimal overhead ## **Error Checking** - **TCP**: Extensive error detection and correction mechanisms - **UDP**: Basic checksum validation only ## **Data Ordering** - **TCP**: Maintains packet order - **UDP**: No ordering guarantee ## **Header Size** - **TCP**: 20-60 bytes - **UDP**: 8 bytes ## **Common Use Cases** | TCP | UDP | |-----|-----| | Email (SMTP, POP3) | Video streaming (YouTube) | | Web browsing (HTTP/HTTPS) | Online gaming | | File transfer (FTP) | VoIP (Skype) | | Remote access (SSH) | DNS queries | | Database connections | Live broadcasting | ## **Summary** - **Choose TCP** when data accuracy and completeness matter (email, banking, browsing) - **Choose UDP** when speed matters more than perfection (streaming, gaming, real-time communication)
brief
rep 1: 47 words
# TCP vs UDP | | TCP | UDP | |---|---|---| | **Connection** | Establishes connection first | Connectionless | | **Reliability** | Guaranteed delivery, ordered | No guarantee, may lose packets | | **Speed** | Slower (more overhead) | Faster | | **Error checking** | Extensive | Minimal | | **Use cases** | Email, web, file transfer | Video streaming, gaming, DNS, VoIP | **Bottom line:** TCP prioritizes accuracy; UDP prioritizes speed.
rep 2: 49 words
# TCP vs UDP | Feature | TCP | UDP | |---------|-----|-----| | **Connection** | Connection-oriented | Connectionless | | **Reliability** | Guaranteed delivery, ordered | No guarantees | | **Speed** | Slower | Faster | | **Overhead** | Higher | Lower | | **Use cases** | Email, web, file transfer | Video, VoIP, gaming | **Simple version:** TCP ensures data arrives correctly; UDP prioritizes speed. Use TCP when accuracy matters, UDP when speed matters.
rep 3: 43 words
# TCP vs UDP | Feature | TCP | UDP | |---------|-----|-----| | **Connection** | Establishes connection | Connectionless | | **Reliability** | Guaranteed delivery | Best effort | | **Order** | Ordered packets | No guarantee | | **Speed** | Slower | Faster | | **Overhead** | Higher | Lower | | **Uses** | Email, web, file transfer | Video streaming, gaming, DNS | **Quick take:** TCP prioritizes accuracy; UDP prioritizes speed.

gpt-5.6-terra

plain
rep 1: 93 words
- **TCP (Transmission Control Protocol)** is connection-oriented: it establishes a connection before sending data. It ensures data arrives reliably, in order, and without duplicates through acknowledgments and retransmissions. It has more overhead and is generally slower. **Used for:** web pages (HTTP/HTTPS), email, file transfers, SSH. - **UDP (User Datagram Protocol)** is connectionless: it sends independent packets without establishing a session. It does not guarantee delivery, ordering, or duplicate prevention, but has much lower overhead and latency. **Used for:** live video/audio, online gaming, DNS, VoIP. In short: **TCP prioritizes reliability; UDP prioritizes speed and low latency.**
rep 2: 103 words
**TCP (Transmission Control Protocol)** is connection-oriented and reliable: - Establishes a connection before sending data. - Guarantees delivery, ordering, and error checking. - Retransmits lost packets and manages congestion. - More overhead and usually higher latency. - Used for web browsing, email, file transfers, SSH. **UDP (User Datagram Protocol)** is connectionless and lightweight: - Sends packets without establishing a connection. - Does not guarantee delivery, order, or duplicate prevention. - No built-in retransmission or congestion control. - Lower overhead and latency. - Used for live video/audio, gaming, DNS, and real-time traffic. In short: **use TCP when correctness and reliable delivery matter; use UDP when speed and low latency matter more than perfect delivery.**
rep 3: 91 words
**TCP** and **UDP** are transport-layer network protocols. - **TCP (Transmission Control Protocol)** is connection-oriented and reliable: - Establishes a connection before sending data. - Guarantees delivery, ordering, and error checking. - Retransmits lost packets and manages congestion. - Used for web pages (HTTP/HTTPS), email, file transfers, SSH. - **UDP (User Datagram Protocol)** is connectionless and lightweight: - Sends packets without establishing a connection. - Does not guarantee delivery, order, or duplicate prevention. - Lower overhead and usually lower latency. - Used for live video/audio, online gaming, DNS, and voice calls. In short: **TCP prioritizes reliability; UDP prioritizes speed and low latency.**
brief
rep 1: 14 words
TCP: connection-oriented, reliable, ordered delivery; slower overhead. UDP: connectionless, best-effort, unordered delivery; lower latency/overhead.
rep 2: 14 words
TCP: connection-oriented, reliable, ordered delivery; higher overhead. UDP: connectionless, best-effort, unordered delivery; lower latency/overhead.
rep 3: 14 words
TCP: connection-oriented, reliable, ordered delivery; slower overhead. UDP: connectionless, no delivery/order guarantee; faster, lightweight.

claude-opus-5

plain
rep 1: 225 words
**TCP** (Transmission Control Protocol) and **UDP** (User Datagram Protocol) are both transport-layer protocols, but they make opposite tradeoffs. ## TCP — reliable, connection-oriented - **Handshake**: establishes a connection (SYN → SYN-ACK → ACK) before data flows. - **Reliable delivery**: acknowledges packets and retransmits lost ones. - **Ordered**: reassembles segments in the order they were sent. - **Flow & congestion control**: adapts sending rate to the receiver and the network. - **Cost**: higher latency, more overhead (20+ byte header), head-of-line blocking when a packet is lost. ## UDP — fast, connectionless - **No handshake**: just fire datagrams at the destination. - **No guarantees**: packets may be lost, duplicated, or arrive out of order. - **Minimal overhead**: 8-byte header, no state to maintain. - **Cost**: the application must handle reliability/ordering itself, if it needs them. ## Quick comparison | | TCP | UDP | |---|---|---| | Connection | Yes | No | | Reliability | Guaranteed | Best-effort | | Ordering | Yes | No | | Header size | 20–60 bytes | 8 bytes | | Speed | Slower | Faster | | Broadcast/multicast | No | Yes | ## Typical uses - **TCP**: HTTP/1.1 and HTTP/2, SSH, SMTP, file transfer — anything where a corrupted or missing byte ruins the result. - **UDP**: DNS, DHCP, VoIP, video streaming, online games, QUIC (and thus HTTP/3) — where stale data is worse than lost data, or where the app builds its own reliability layer. **Rule of thumb**: choose TCP when every byte must arrive; choose UDP when timeliness matters more than completeness, or when you want to implement custom delivery semantics (as QUIC does on top of UDP).
rep 2: 258 words
Both are transport-layer protocols that sit on top of IP, but they make opposite tradeoffs. **TCP (Transmission Control Protocol)** — reliable, connection-oriented - Establishes a connection first (three-way handshake: SYN, SYN-ACK, ACK) - Guarantees delivery: lost packets are retransmitted - Guarantees order: data arrives in the sequence it was sent - Flow control (won't overwhelm a slow receiver) and congestion control (backs off when the network is strained) - Higher overhead: 20+ byte header, plus handshake and acknowledgment round-trips **UDP (User Datagram Protocol)** — unreliable, connectionless - Just fires datagrams off; no handshake, no connection state - No delivery guarantee, no ordering, no retransmission - No flow or congestion control by default - Tiny 8-byte header, minimal latency - Supports multicast/broadcast (TCP can't) **The core tradeoff:** TCP trades latency for reliability. When a packet is lost, TCP stalls everything behind it waiting for the retransmission (head-of-line blocking). UDP just keeps going — the missing data is simply gone. **When each wins** | Use case | Protocol | Why | |---|---|---| | Web, email, file transfer | TCP | Corrupted or missing bytes are unacceptable | | Live video/voice calls | UDP | A dropped frame is better than a frozen stream | | Online gaming | UDP | Stale position data is useless; send the next update instead | | DNS queries | UDP | One small request/response — a handshake would double the cost | **A nuance worth knowing:** "UDP is unreliable" doesn't mean applications using it are. Modern protocols like QUIC (which HTTP/3 runs on) build reliability, ordering, and congestion control *on top of* UDP in userspace. This gives them TCP-like guarantees while avoiding head-of-line blocking across independent streams and allowing faster iteration than changes to kernel TCP stacks would permit.
rep 3: 310 words
Both are transport-layer protocols that sit on top of IP, but they make opposite tradeoffs. **TCP (Transmission Control Protocol)** — reliable, connection-oriented - Establishes a connection first (3-way handshake: SYN, SYN-ACK, ACK) - Guarantees delivery: lost packets are retransmitted - Guarantees ordering: data arrives in the sequence it was sent - Flow control (receiver advertises a window) and congestion control (slows down when the network is loaded) - Higher overhead: 20+ byte header, plus handshake and ACK round-trips add latency - Stream-oriented: no message boundaries — you read a byte stream **UDP (User Datagram Protocol)** — unreliable, connectionless - No handshake, just fire packets off - No delivery guarantee, no ordering guarantee, no retransmission - No flow or congestion control (your app must handle it) - Low overhead: 8-byte header, no round-trips before sending - Datagram-oriented: each packet is a discrete message with preserved boundaries - Supports multicast/broadcast; TCP does not **When each is used** | Use case | Protocol | Why | |---|---|---| | Web (HTTP/1.1, HTTP/2), email, SSH, file transfer | TCP | Correctness matters more than latency | | DNS lookups | UDP | Single small request/response; retry is cheaper than a handshake | | Live voice/video, game state updates | UDP | A late packet is useless — better to drop it and move on | | DHCP, mDNS, streaming discovery | UDP | Needs broadcast/multicast | **The mental model:** TCP is a phone call — you connect, confirm the other side is there, and both sides notice if the line drops. UDP is dropping postcards in a mailbox — cheap and fast, but you don't know if any arrived or in what order. **Worth knowing:** the line has blurred. QUIC (the basis of HTTP/3) runs *on top of* UDP but reimplements reliability, ordering, and congestion control in userspace. This lets it fix TCP's weaknesses — notably head-of-line blocking, where one lost packet stalls all multiplexed streams — and cut connection setup to fewer round-trips by folding in the TLS handshake. So "UDP" today often means "we're building our own transport," not "we don't care about reliability."
brief
rep 1: 16 words
TCP: connection-based, reliable, ordered, slower. UDP: connectionless, no guarantees, faster. TCP for web/email/files; UDP for streaming/gaming/DNS.
rep 2: 20 words
TCP: connection-based, reliable, ordered, slower. Think file transfers, web pages. UDP: connectionless, no guarantees, faster. Think video calls, games, DNS.
rep 3: 16 words
TCP: connection-based, reliable, ordered, slower. UDP: connectionless, no guarantees, fast. TCP for web/email/files; UDP for streaming/gaming/DNS.

claude-opus-5-5

plain
rep 1: 335 words
TCP (Transmission Control Protocol) and UDP (User Datagram Protocol) are both transport-layer protocols. They differ mainly in how much they guarantee about delivery. ## TCP: reliable and connection-oriented - **Connection setup:** It establishes a connection with a three-way handshake (SYN → SYN-ACK → ACK) before sending data. - **Reliable delivery:** It acknowledges received data and retransmits anything that gets lost. - **Ordered:** Data arrives in the order it was sent. - **Byte stream:** Data is a continuous stream with no message boundaries. - **Flow and congestion control:** It adjusts its sending rate to avoid overwhelming the receiver or the network. - **Error checking:** It uses checksums plus retransmission. - **Overhead:** The header is larger (20–60 bytes), and handshakes and ACKs add latency. ## UDP: lightweight and connectionless - **No setup:** It sends packets (datagrams) immediately, without a handshake. - **Best-effort delivery:** Packets may be lost, duplicated, or arrive out of order, and there's no retransmission. - **Message-oriented:** Each datagram is a discrete unit with preserved boundaries. - **No flow or congestion control:** It sends as fast as the application wants. - **Minimal error checking:** It has a checksum, but corrupted packets are simply dropped. - **Low overhead:** The header is only 8 bytes, which keeps latency low. ## Quick comparison | Feature | TCP | UDP | |---|---|---| | Connection | Connection-oriented | Connectionless | | Reliability | Guaranteed delivery | Best effort | | Ordering | Preserved | Not guaranteed | | Speed | Slower, more overhead | Faster, less overhead | | Header size | 20–60 bytes | 8 bytes | | Broadcast/multicast | No | Yes | ## Typical use cases **TCP** fits when correctness matters more than speed: - Web browsing (HTTP/1.1, HTTP/2) - Email (SMTP, IMAP) - File transfer (FTP, SFTP) - SSH and database connections **UDP** fits when speed matters more than perfect delivery: - Live video and voice calls (VoIP, WebRTC) - Online gaming - DNS lookups - Streaming and broadcasting - DHCP ## Note on modern protocols **QUIC**, the transport under HTTP/3, runs on top of UDP but builds reliability, encryption, and multiplexing into the protocol itself. It gets TCP-like guarantees with lower latency and without TCP's head-of-line blocking. **In short:** TCP is like certified mail, reliable but slower. UDP is like shouting across a room: fast, but you don't know if everything was heard.
rep 2: 289 words
TCP and UDP are both transport-layer protocols, but they make opposite trade-offs between **reliability** and **speed**. ## TCP (Transmission Control Protocol) - **Connection-oriented**: Establishes a connection with a three-way handshake (SYN, SYN-ACK, ACK) before sending data. - **Reliable**: Acknowledges received data and retransmits lost packets. - **Ordered**: Data arrives in the order it was sent. - **Flow and congestion control**: Adjusts its sending rate so it doesn't overwhelm the receiver or the network. - **Byte stream**: Data is a continuous stream with no message boundaries. - **Higher overhead**: 20–60 byte header, plus the cost of handshakes and acknowledgments. ## UDP (User Datagram Protocol) - **Connectionless**: Just sends packets (datagrams), with no handshake. - **Unreliable**: No acknowledgments or retransmission. Packets can be lost, duplicated, or arrive out of order. - **No flow or congestion control**: Sends as fast as the application wants. - **Message-oriented**: Each datagram is a self-contained unit, so message boundaries are preserved. - **Low overhead**: 8-byte header and minimal latency. ## Quick Comparison | Feature | TCP | UDP | |---|---|---| | Connection | Required (handshake) | None | | Delivery guarantee | Yes | No | | Ordering | Guaranteed | Not guaranteed | | Speed / latency | Slower | Faster | | Header size | 20–60 bytes | 8 bytes | | Broadcast/multicast | No | Yes | ## Typical Use Cases **TCP**, when correctness matters more than speed: - Web browsing (HTTP/1.1, HTTP/2) - Email (SMTP, IMAP) - File transfer (FTP, SFTP) - SSH, databases **UDP**, when speed matters more than perfect delivery: - Live video and voice calls (VoIP, WebRTC) - Online gaming - DNS lookups - Streaming, IoT telemetry - **QUIC / HTTP/3**, which builds its own reliability on top of UDP to avoid some of TCP's limitations ## Analogy - **TCP** is like a phone call. You connect first, confirm the other person hears you, and repeat anything that was missed. - **UDP** is like mailing postcards. You send them off, and most arrive, but some may get lost or arrive out of order, and you won't know.
rep 3: 316 words
TCP and UDP are both transport-layer protocols that carry data over IP networks. They make opposite trade-offs: **TCP favors reliability, UDP favors speed and simplicity.** ## TCP (Transmission Control Protocol) - **Connection-oriented:** Establishes a connection with a three-way handshake (SYN → SYN-ACK → ACK) before sending data. - **Reliable delivery:** Acknowledges received data and retransmits lost packets. - **Ordered:** Data arrives in the order it was sent, using sequence numbers. - **Flow control:** Keeps a fast sender from overwhelming a slow receiver (sliding window). - **Congestion control:** Slows down when the network is congested. - **Byte stream:** Data is a continuous stream with no message boundaries. - **Header size:** 20–60 bytes. ## UDP (User Datagram Protocol) - **Connectionless:** No handshake; it just sends packets ("datagrams"). - **Unreliable:** No acknowledgments or retransmissions, so packets can be lost. - **Unordered:** Packets may arrive out of order or duplicated. - **No flow or congestion control:** Sends as fast as the application wants. - **Message-oriented:** Each datagram is a self-contained unit with preserved boundaries. - **Header size:** 8 bytes. ## Side-by-Side | Feature | TCP | UDP | |---|---|---| | Connection | Required (handshake) | None | | Reliability | Guaranteed | Best-effort | | Ordering | Guaranteed | Not guaranteed | | Speed / latency | Higher overhead | Lower overhead | | Header size | 20+ bytes | 8 bytes | | Broadcast/multicast | No | Yes | ## Typical Use Cases **TCP:** web browsing (HTTP/1.1, HTTP/2), email (SMTP, IMAP), file transfer (FTP, SFTP), SSH, and databases. These need every byte to arrive intact. **UDP:** DNS lookups, video and voice calls (VoIP, WebRTC), online gaming, live streaming, and DHCP. For these, a late packet is worse than a lost one. ## Analogy - **TCP** is like a phone call. You connect first, confirm the other person heard you, and repeat anything they missed. - **UDP** is like mailing postcards. You send them off without knowing if or in what order they'll arrive. ## Modern Note **QUIC**, the protocol behind HTTP/3, runs on top of UDP but adds reliability, encryption, and congestion control in user space. This avoids some TCP limitations, such as head-of-line blocking and slow connection setup, while keeping reliability.
brief
rep 1: 37 words
**TCP**: connection-oriented, reliable, ordered delivery, retransmits lost data, flow/congestion control. Slower, more overhead. Used for web, email, file transfer. **UDP**: connectionless, no delivery or order guarantees, no retransmission. Faster, minimal overhead. Used for streaming, gaming, DNS, VoIP.
rep 2: 36 words
**TCP:** connection-based, reliable, ordered, error-checked, retransmits lost packets, flow/congestion control. Slower, more overhead. Used for web, email, file transfer. **UDP:** connectionless, no delivery or order guarantees, no retransmission. Faster, lightweight. Used for streaming, gaming, VoIP, DNS.
rep 3: 36 words
**TCP**: connection-oriented, reliable (acknowledgments, retransmission), ordered delivery, flow/congestion control. Slower, more overhead. Used for web, email, file transfer. **UDP**: connectionless, no delivery or order guarantees, minimal overhead. Faster, lower latency. Used for streaming, gaming, DNS, VoIP.
sort-stable: Is Python's list.sort() stable?

Reference answer: Yes.

claude-haiku-4-5

plain
rep 1: 151 words
# Yes, Python's `list.sort()` is stable Python's `list.sort()` method is **guaranteed to be stable**. This means that when sorting elements with equal keys, their original relative order is preserved. ## Example ```python # List of tuples (name, score) students = [('Alice', 85), ('Bob', 90), ('Charlie', 85), ('David', 90)] # Sort by score only (index 1) students.sort(key=lambda x: x[1]) print(students) # Output: [('Alice', 85), ('Charlie', 85), ('Bob', 90), ('David', 90)] ``` Notice that: - Among score 85: Alice comes before Charlie (original order preserved) - Among score 90: Bob comes before David (original order preserved) ## History - **Guaranteed stable since Python 2.3** (released in 2003) - Uses **Timsort algorithm**, which is inherently stable - The `sorted()` built-in function also uses the same algorithm, so it's stable too ## Why This Matters Stability is useful when you sort by multiple criteria sequentially: ```python students.sort(key=lambda x: x[0]) # Sort by name first students.sort(key=lambda x: x[1]) # Then by score # Result: sorted by score, with names alphabetical within each score ```
rep 2: 173 words
# Yes, Python's `list.sort()` is stable Python's `list.sort()` method **is guaranteed to be stable**. This means that when two elements compare as equal, they maintain their relative order from the original list. ## Key Details - **Stable sort guarantee**: Elements with equal keys retain their original relative order - **Algorithm**: Python uses **Timsort**, a hybrid algorithm that combines merge sort and insertion sort - **Documentation**: This stability is officially documented and guaranteed behavior - **Since Python 2.3**: This has been true for many years ## Example ```python data = [(1, 'a'), (2, 'b'), (1, 'c'), (2, 'd')] # Sort by first element only data.sort(key=lambda x: x[0]) print(data) # Output: [(1, 'a'), (1, 'c'), (2, 'b'), (2, 'd')] # Notice: (1, 'a') comes before (1, 'c'), and (2, 'b') before (2, 'd') # This is because of the stable sort preserving original order ``` ## Practical Benefit Stability is useful for **multi-key sorting**: ```python # First sort by secondary key data.sort(key=lambda x: x[1]) # Then sort by primary key - secondary order is preserved for ties data.sort(key=lambda x: x[0]) ``` The same stability applies to **`sorted()`** built-in function, which also uses Timsort.
rep 3: 138 words
# Python's list.sort() Stability Yes, **Python's `list.sort()` is stable**. This has been guaranteed since Python 2.3. ## What Does Stable Mean? A stable sort preserves the relative order of elements with equal keys. If two elements compare as equal, they maintain their original relative positions. ## Example ```python # List of tuples: (age, name) people = [(25, 'Alice'), (30, 'Bob'), (25, 'Charlie'), (30, 'Diana')] # Sort by age only people.sort(key=lambda x: x[0]) print(people) # Output: [(25, 'Alice'), (25, 'Charlie'), (30, 'Bob'), (30, 'Diana')] ``` Notice that within each age group, the original order is preserved: - `(25, 'Alice')` comes before `(25, 'Charlie')` ✓ - `(30, 'Bob')` comes before `(30, 'Diana')` ✓ ## Related Functions The stability guarantee also applies to: - **`sorted()`** - built-in function (stable) - **`heapq.heapify()`, `heapq.heappop()`, etc.** - heap operations (not stable) The stability of `list.sort()` and `sorted()` makes them reliable for multi-level sorting and other applications where maintaining original order matters.
brief
rep 1: 23 words
Yes, Python's `list.sort()` is stable. Elements with equal values retain their original relative order after sorting. This has been guaranteed since Python 2.3.
rep 2: 16 words
Yes. Python's `list.sort()` is stable — elements with equal values maintain their original relative order after sorting.
rep 3: 23 words
Yes. Python's `list.sort()` is stable. It uses Timsort, a hybrid stable sorting algorithm that preserves the relative order of elements with equal keys.

gpt-5.6-terra

plain
rep 1: 47 words
Yes. Python’s `list.sort()` is **stable**: if two elements compare equal, their original relative order is preserved. ```python items = [('a', 2), ('b', 1), ('c', 2)] items.sort(key=lambda x: x[1]) print(items) # [('b', 1), ('a', 2), ('c', 2)] ``` `('a', 2)` remains before `('c', 2)`. Python uses Timsort, a stable sorting algorithm.
rep 2: 53 words
Yes. Python’s `list.sort()` is stable: items that compare equal retain their original relative order. It uses Timsort, which is stable. For example: ```python items = [("a", 2), ("b", 1), ("c", 2)] items.sort(key=lambda x: x[1]) print(items) # [('b', 1), ('a', 2), ('c', 2)] ``` `("a", 2)` remains before `("c", 2)` because both have the same sort key.
rep 3: 44 words
Yes. Python’s `list.sort()` is **stable**: items that compare equal retain their original relative order. ```python items = [('a', 2), ('b', 1), ('c', 2)] items.sort(key=lambda x: x[1]) # [('b', 1), ('a', 2), ('c', 2)] ``` `('a', 2)` remains before `('c', 2)` because both have the same sort key.
brief
rep 1: 10 words
Yes. `list.sort()` is stable: equal items retain their original order.
rep 2: 10 words
Yes. `list.sort()` is stable: equal elements retain their original order.
rep 3: 9 words
Yes. `list.sort()` is stable: equal keys retain original order.

claude-opus-5

plain
rep 1: 67 words
Yes. `list.sort()` (and `sorted()`) are guaranteed stable — records with equal keys keep their original relative order. This is a documented language guarantee, not just an implementation detail. It's implemented via Timsort (an adaptive merge sort). A practical consequence: you can sort by multiple keys with successive sorts, applying them in reverse order of priority: ```python data.sort(key=lambda r: r.name) # secondary key first data.sort(key=lambda r: r.age) # primary key last ```
rep 2: 77 words
Yes. `list.sort()` (and `sorted()`) are guaranteed stable — records with equal keys retain their original relative order. This is part of the language spec, not just a CPython detail. This lets you sort by multiple keys with successive passes, applying them in reverse order of priority: ```python data.sort(key=lambda r: r.name) # secondary key first data.sort(key=lambda r: r.dept) # primary key last ``` Both use Timsort, which exploits existing runs in the data (O(n) on already-sorted input, O(n log n) worst case).
rep 3: 104 words
Yes. Python's `list.sort()` (and the built-in `sorted()`) are guaranteed stable — records with equal keys retain their original relative order. This is a documented language guarantee, not just an implementation detail. It's useful for multi-key sorting: sort by the least significant key first, then by the more significant one. ```python data = [("bob", 2), ("alice", 1), ("carol", 2), ("dave", 1)] data.sort(key=lambda x: x[0]) # secondary: name data.sort(key=lambda x: x[1]) # primary: number # [('alice', 1), ('dave', 1), ('bob', 2), ('carol', 2)] ``` Under the hood it's Timsort (adaptive merge sort), which is stable by design. Note that `sort()` mutates in place and returns `None`, while `sorted()` returns a new list.
brief
rep 1: 1 words
Yes.
rep 2: 1 words
Yes.
rep 3: 1 words
Yes.

claude-opus-5-5

plain
rep 1: 133 words
Yes. `list.sort()` is **guaranteed to be stable**: elements that compare equal keep their original relative order. The same holds for the built-in `sorted()`. This has been a documented language guarantee since Python 2.2, so you can rely on it rather than treating it as an implementation detail. CPython implements it with Timsort, and since 3.11 it uses a refined merge strategy (Powersort) that is still stable. **Why it matters:** you can do multi-key sorts by sorting in passes, from the least significant key to the most significant: ```python records = [("alice", 30), ("bob", 25), ("carol", 30), ("dave", 25)] records.sort(key=lambda r: r[0]) # secondary key: name records.sort(key=lambda r: r[1]) # primary key: age # [('bob', 25), ('dave', 25), ('alice', 30), ('carol', 30)] ``` Stability also holds with `reverse=True`. Equal elements stay in their original order rather than being flipped.
rep 2: 123 words
Yes. `list.sort()` and `sorted()` are both **guaranteed stable**. When two elements compare equal, they keep their original relative order. This is part of the language specification, not an implementation detail. It has been guaranteed since Python 2.2. The algorithm is Timsort, and CPython 3.11+ uses Powersort-style merge logic. Stability lets you sort by several keys in multiple passes, starting with the least significant key: ```python records = [("alice", 30), ("bob", 25), ("carol", 30), ("dave", 25)] records.sort(key=lambda r: r[0]) # secondary key: name records.sort(key=lambda r: r[1]) # primary key: age # [('bob', 25), ('dave', 25), ('alice', 30), ('carol', 30)] ``` Within each age group, the names stay in alphabetical order from the first sort. Stability also holds with `reverse=True`. Equal elements keep their original order rather than being flipped.
rep 3: 161 words
Yes. Python's `list.sort()` is **guaranteed to be stable**, and so is the built-in `sorted()`. When two elements compare equal, they keep their original relative order. This is part of the language specification, not just an implementation detail. The guarantee has been documented since Python 2.2. The underlying algorithm was Timsort, and since Python 3.11 it has been a variant called Powersort. **Example:** ```python data = [("apple", 2), ("banana", 1), ("cherry", 2), ("date", 1)] data.sort(key=lambda x: x[1]) print(data) # [('banana', 1), ('date', 1), ('apple', 2), ('cherry', 2)] ``` Within each group, "banana" stays before "date" and "apple" stays before "cherry", just as they were in the original list. **Why it matters:** Stability lets you sort by multiple keys in passes, sorting by the secondary key first and then by the primary key: ```python records.sort(key=lambda r: r.name) # secondary records.sort(key=lambda r: r.age) # primary # Result: sorted by age, ties broken by name ``` Stability also holds with `reverse=True`. Equal elements still keep their original order rather than being flipped.
brief
rep 1: 10 words
Yes. Guaranteed stable since Python 2.2 (Timsort). `sorted()` is too.
rep 2: 14 words
Yes. It's guaranteed stable (Timsort/Powersort): equal elements keep their original order. Same for `sorted()`.
rep 3: 17 words
Yes. Guaranteed stable since Python 2.2 (Timsort). Equal elements keep their original order. `sorted()` is stable too.
uptime-downtime: A service promises 99.9% uptime. How much downtime does that allow in a 30-day month?

Reference answer: 43.2 minutes

claude-haiku-4-5

plain
rep 1: 80 words
# 99.9% Uptime Downtime Calculation If a service is up 99.9% of the time, it's down **0.1%** of the time. **In a 30-day month:** - Total hours: 30 days × 24 hours = **720 hours** - Allowed downtime: 720 hours × 0.1% = 720 × 0.001 = **0.72 hours** - **≈ 43.2 minutes** (or about **43 minutes and 12 seconds**) So 99.9% uptime allows roughly **43 minutes of downtime per month**. This is often called **"three nines"** reliability, which is a common SLA (Service Level Agreement) target for many cloud services.
rep 2: 74 words
# 99.9% Uptime Downtime Calculation For a 30-day month with 99.9% uptime: **Downtime = 0.1% of 30 days** Converting to practical units: - **30 days** = 720 hours = 43,200 minutes - **0.1% of 43,200 minutes** = **43.2 minutes** ## Answer: **~43 minutes and 12 seconds** Or expressed differently: - **0.72 hours** per month - About **10 minutes per week** (rough average) This is often called "three nines" (99.9%) in the industry and is a common SLA (Service Level Agreement) target for many services.
rep 3: 65 words
# 99.9% Uptime in a 30-Day Month With 99.9% uptime, the service can be down **0.1%** of the time. **Calculation:** - 30 days = 43,200 minutes - 0.1% × 43,200 minutes = **43.2 minutes** **That's approximately 43 minutes and 12 seconds of allowed downtime per month.** --- **For reference, here are common uptime levels:** | Uptime % | Monthly Downtime | |----------|------------------| | 99% | ~7.2 hours | | 99.9% | ~43 minutes | | 99.95% | ~22 minutes | | 99.99% | ~4.3 minutes | | 99.999% | ~26 seconds |
brief
rep 1: 21 words
**43.2 minutes** 99.9% uptime = 0.1% downtime 30 days × 24 hours × 60 minutes = 43,200 total minutes 0.1% × 43,200 = **43.2 minutes** downtime allowed
rep 2: 15 words
**43.2 minutes** Calculation: - 30 days = 720 hours - 0.1% downtime = 0.001 × 720 = 0.72 hours = 43.2 minutes
rep 3: 14 words
**43.2 minutes** Calculation: - 30 days = 720 hours - 0.1% of 720 = 0.72 hours = 43.2 minutes

gpt-5.6-terra

plain
rep 1: 26 words
99.9% uptime allows **0.1% downtime**. In a 30-day month: 30 × 24 = 720 hours 0.1% of 720 hours = **0.72 hours** = **43.2 minutes** (about **43 minutes 12 seconds**).
rep 2: 14 words
99.9% uptime allows **0.1% downtime**. For 30 days: **43 minutes 12 seconds** of downtime.
rep 3: 21 words
99.9% uptime permits **0.1% downtime**. For a 30-day month: **30 × 24 × 0.001 = 0.72 hours = 43.2 minutes**, or **43 minutes 12 seconds**.
brief
rep 1: 6 words
43.2 minutes (≈43 min 12 sec).
rep 2: 4 words
43 minutes 12 seconds.
rep 3: 4 words
43.2 minutes (43m 12s).

claude-opus-5

plain
rep 1: 67 words
**43.2 minutes** (about 43 minutes, 12 seconds). Math: 30 days × 24 h = 720 hours = 43,200 minutes. 0.1% of 43,200 = 43.2. For reference at 99.9%: - Per day: ~1.44 minutes - Per week: ~10.1 minutes - Per 365-day year: ~8.76 hours One caveat worth checking in the actual SLA: many providers measure uptime per calendar month and exclude scheduled maintenance windows, so the effective allowance can be larger than 43.2 minutes.
rep 2: 38 words
**About 43.2 minutes.** 30 days × 24 h = 720 hours = 43,200 minutes. Allowed downtime = 0.1% × 43,200 = **43.2 minutes** (43 min 12 sec). For reference, at 99.9%: - Per day: ~1.44 minutes - Per week: ~10.1 minutes - Per 365-day year: ~8.76 hours
rep 3: 39 words
**43.2 minutes** (about 43 min 12 sec). Math: 30 days × 24 h = 720 hours = 43,200 minutes. 0.1% of 43,200 = 43.2. For reference, at 99.9%: - Per day: ~1.44 minutes - Per week: ~10.1 minutes - Per 365-day year: ~8 h 46 min
brief
rep 1: 6 words
43.2 minutes (0.1% of 43,200 min).
rep 2: 6 words
43.2 minutes (0.1% of 43,200 minutes).
rep 3: 6 words
43.2 minutes (0.1% of 43,200 min).

claude-opus-5-5

plain
rep 1: 34 words
99.9% uptime allows **43.2 minutes of downtime** in a 30-day month. - 30 days × 24 hours × 60 minutes = 43,200 minutes - Allowed downtime is 0.1% of that: 43,200 × 0.001 = **43.2 minutes** (about 43 minutes 12 seconds)
rep 2: 35 words
A 99.9% uptime guarantee allows about **43.2 minutes** of downtime in a 30-day month. - 30 days × 24 hours × 60 minutes = 43,200 minutes - 0.1% of that is 43,200 × 0.001 = **43.2 minutes** (about 43 minutes 12 seconds)
rep 3: 51 words
99.9% uptime allows **43.2 minutes** of downtime in a 30-day month. **Calculation:** - 30 days × 24 hours × 60 minutes = 43,200 minutes - Allowed downtime = 0.1% × 43,200 = **43.2 minutes** (about 43 minutes, 12 seconds) For comparison, over 30 days: | Uptime | Allowed downtime | |---|---| | 99% | 7.2 hours | | 99.9% | 43.2 minutes | | 99.99% | 4.32 minutes | | 99.999% | ~26 seconds |
brief
rep 1: 8 words
**43.2 minutes**, which is 0.1% of 43,200 minutes.
rep 2: 5 words
**43.2 minutes** (0.1% × 43,200 minutes).
rep 3: 5 words
**43.2 minutes** (0.1% × 43,200 minutes).
idempotent: What does it mean for an HTTP method to be idempotent?

Reference answer: Repeating the request has the same effect as sending it once.

claude-haiku-4-5

plain
rep 1: 199 words
# Idempotent HTTP Methods An HTTP method is **idempotent** if making the same request multiple times produces the same result as making it a single time. In other words, repeated identical calls have no additional side effects beyond the first call. ## Key Examples **Idempotent methods:** - **GET** - Retrieving data doesn't change anything - **HEAD** - Like GET, but without the response body - **PUT** - Updating a resource to a specific state is idempotent (the end result is the same) - **DELETE** - Deleting a resource multiple times results in it being deleted (subsequent calls may return 404, but the state is the same) - **OPTIONS** - Just querying capabilities - **TRACE** - Diagnostic method **Non-idempotent methods:** - **POST** - Creating a resource multiple times creates multiple resources - **PATCH** - May apply relative changes that compound with repeated calls ## Practical Example ``` GET /api/users/1 → Returns user data (idempotent, no changes) DELETE /api/users/1 → Deletes user (idempotent, already deleted after first call) POST /api/users → Creates new user (NOT idempotent, creates multiple users) ``` ## Why It Matters - **Reliability**: Clients can safely retry idempotent requests without worrying about unintended consequences - **Caching**: Idempotent methods can be cached - **Network issues**: If the connection drops after sending a request, clients can safely retry This is an important distinction for building robust, fault-tolerant APIs.
rep 2: 203 words
# HTTP Idempotence An HTTP method is **idempotent** if making the same request multiple times produces the same result (and side effects) as making it once. ## Key Concept Repeated identical calls should not cause unintended changes beyond the first call. ## Idempotent Methods | Method | Idempotent? | Why | |--------|-------------|-----| | **GET** | ✅ Yes | Only retrieves data, no modifications | | **PUT** | ✅ Yes | Replaces a resource completely; calling it again with the same data leaves it unchanged | | **DELETE** | ✅ Yes | Deleting an already-deleted resource returns 404 (same state achieved) | | **HEAD** | ✅ Yes | Same as GET but without the response body | | **OPTIONS** | ✅ Yes | Only retrieves metadata about allowed methods | ## Non-Idempotent Methods | Method | Why Not | |--------|---------| | **POST** | Creates new resources; calling it multiple times creates duplicates | | **PATCH** | Applies partial modifications; repeated calls may produce different results | ## Practical Example ``` PUT /api/users/123 with {"name": "Alice"} → Call 1: User updated to Alice → Call 2: User updated to Alice (same result) → Call 3: User updated to Alice (same result) ✅ Idempotent POST /api/users with {"name": "Bob"} → Call 1: Bob created (id: 1) → Call 2: Bob created again (id: 2) → Call 3: Bob created again (id: 3) ❌ Not idempotent ``` ## Why It Matters Idempotence allows safe retries—clients can safely retry idempotent requests if a network failure occurs without worrying about duplicates or unintended side effects.
rep 3: 178 words
# HTTP Idempotency An **idempotent** HTTP method means that making the same request multiple times produces the same result as making it just once. In other words, repeated identical requests don't cause additional side effects. ## Key Characteristics - **First request**: Executes normally and produces a result - **Subsequent requests**: Produce the same result without additional changes to the server state ## Idempotent HTTP Methods | Method | Idempotent | Notes | |--------|-----------|-------| | **GET** | ✅ Yes | Retrieves data without modification | | **HEAD** | ✅ Yes | Like GET, but without response body | | **PUT** | ✅ Yes | Replaces a resource (same state each time) | | **DELETE** | ✅ Yes | Deleting twice leaves same result | | **POST** | ❌ No | Creates new resources (multiple calls create duplicates) | | **PATCH** | ❌ No | May apply partial updates differently each time | ## Examples ### Idempotent (PUT) ``` PUT /users/123 { "name": "John" } # First call: Creates/updates user → John # Second call: Creates/updates user → John (same result) ``` ### Non-Idempotent (POST) ``` POST /users { "name": "John" } # First call: Creates user #1 → John # Second call: Creates user #2 → John (different result) ``` ## Why It Matters Idempotency is crucial for: - **Reliability**: Clients can safely retry failed requests - **Network resilience**: Handling lost responses without duplicating actions - **Caching**: Safe to cache idempotent requests
brief
rep 1: 53 words
An HTTP method is **idempotent** if calling it multiple times produces the same result as calling it once. **Idempotent methods:** GET, PUT, DELETE, HEAD, OPTIONS **Non-idempotent:** POST (each call creates a new resource) Example: Calling DELETE on the same resource twice removes it the first time; the second call has no additional effect.
rep 2: 61 words
An HTTP method is **idempotent** if calling it multiple times with the same parameters produces the same result as calling it once. **Idempotent methods:** GET, PUT, DELETE, HEAD, OPTIONS, TRACE **Non-idempotent:** POST, PATCH (may create/modify multiple resources if repeated) Example: DELETE `/user/5` removes that user whether called once or 100 times. POST `/users` creates a new user each time it's called.
rep 3: 51 words
An HTTP method is **idempotent** if making the same request multiple times produces the same result as making it once. **Examples:** - **GET, PUT, DELETE**: idempotent (no additional side effects from repeating) - **POST**: not idempotent (repeating creates multiple resources) In short: repeated identical calls don't cause additional changes beyond the first call.

gpt-5.6-terra

plain
rep 1: 99 words
An HTTP method is **idempotent** if making the same request multiple times has the same intended effect on the server as making it once. For example: - `GET /users/42` is idempotent: repeated reads don’t change the resource. - `PUT /users/42` with the same full replacement is idempotent: sending it again leaves the resource in the same state. - `DELETE /users/42` is idempotent: deleting an already-deleted resource should not cause additional change. `POST` is generally **not** idempotent, because sending it twice may create two separate resources or charges. Idempotency concerns the server’s resulting state—not necessarily identical response codes or bodies on every retry.
rep 2: 96 words
An HTTP method is **idempotent** if making the same request multiple times has the same intended effect on the server as making it once. Examples: - **GET**: Repeating it only retrieves the resource again—idempotent. - **PUT**: Setting a resource to the same representation repeatedly leaves it in the same state—idempotent. - **DELETE**: Deleting a resource repeatedly still results in it being absent—idempotent, even if later requests return `404`. Usually **POST** is *not* idempotent: sending the same “create order” request twice may create two orders. Idempotence concerns the server’s state, not necessarily identical responses or side effects such as logging.
rep 3: 98 words
An HTTP method is **idempotent** if making the same request multiple times has the same intended effect on the server as making it once. Examples: - `GET /users/42` repeatedly fetches the same resource—no server-state change. - `PUT /users/42` with the same full representation repeatedly leaves it in that representation. - `DELETE /users/42` repeatedly means it remains deleted, even if later calls return `404`. Common idempotent methods: `GET`, `HEAD`, `PUT`, `DELETE`, `OPTIONS`. `POST` is generally **not** idempotent: sending it twice might create two orders, payments, or records. Idempotency concerns the server’s state/effect, not necessarily identical response codes or bodies on every retry.
brief
rep 1: 20 words
An HTTP method is idempotent if repeating the same request has the same intended server effect as sending it once.
rep 2: 20 words
An HTTP method is idempotent if repeating the same request has the same intended server effect as making it once.
rep 3: 20 words
An HTTP method is **idempotent** if repeating the same request has the same intended server effect as sending it once.

claude-opus-5

plain
rep 1: 316 words
An HTTP method is **idempotent** if making the same request multiple times has the same effect on the server's state as making it once. The key points: - **It's about server state, not responses.** `DELETE /users/42` returns 204 the first time and maybe 404 the second — different responses, but the resource is gone either way, so it's still idempotent. - **It's about the *intended* effect, not incidental changes.** Logging, analytics counters, and `last_accessed` timestamps don't break idempotency. **The methods:** | Method | Idempotent | Safe | |---|---|---| | GET, HEAD, OPTIONS, TRACE | ✅ | ✅ | | PUT, DELETE | ✅ | ❌ | | POST | ❌ | ❌ | | PATCH | ❌ (not guaranteed) | ❌ | *Safe* is a stricter property: the method shouldn't modify state at all. All safe methods are idempotent, but not vice versa. **Why PUT vs POST differs:** `PUT /users/42` with a full body sets that resource to a known value — running it ten times leaves the same state. `POST /users` creates a *new* resource each time, so ten calls give you ten users. **PATCH is the interesting case.** It *can* be idempotent — `{"status": "archived"}` is. But it isn't required to be, because a patch can be relative: `{"op": "increment", "field": "views"}` changes state every time. The spec therefore declines to guarantee it. **Why it matters practically:** - **Safe retries.** If a client times out and doesn't know whether the request landed, it can retry an idempotent request without risk. This is why HTTP libraries, proxies, and load balancers auto-retry GET/PUT but generally won't auto-retry POST. - **Idempotency keys.** Since POST isn't idempotent, APIs handling payments (Stripe, etc.) add an `Idempotency-Key` header. The server records the key and returns the cached original response on a replay — bolting idempotency onto a non-idempotent method so a network blip can't double-charge someone. One common gotcha: idempotency says nothing about *concurrency*. Two identical PUTs racing against each other, interleaved with a third party's write, can still produce surprising results. For that you want conditional requests (`If-Match` with an ETag), which is a separate mechanism.
rep 2: 266 words
An HTTP method is **idempotent** if making the same request multiple times has the same effect on server state as making it once. **Key points:** - It's about *server-side state*, not the response. A `DELETE /users/42` returns `204` the first time and maybe `404` after — different responses, but the resource is gone either way, so it's still idempotent. - It's about *identical repeated requests*, not concurrency. Interleaved requests from other clients don't break the guarantee. **By method:** | Method | Idempotent | Safe | |---|---|---| | GET, HEAD, OPTIONS, TRACE | ✅ | ✅ | | PUT, DELETE | ✅ | ❌ | | POST | ❌ | ❌ | | PATCH | ❌ (not required) | ❌ | *Safe* means "read-only" — a stronger property. All safe methods are idempotent, but not vice versa. **Why PUT vs POST:** `PUT /users/42` with a full body sets that resource to a specific value — do it ten times, same result. `POST /users` creates a new resource each time, so ten calls means ten users. **PATCH** is interesting: it *can* be idempotent depending on the patch. `{"status": "active"}` is; `{"op": "increment", "field": "views"}` isn't. The spec deliberately doesn't require it. **Why it matters:** Idempotency is what makes automatic retries safe. If a client times out waiting on a `PUT`, it can just resend — the request may have succeeded, but resending does no harm. With `POST`, a retry risks a duplicate charge or order. That's why payment APIs (Stripe, etc.) add an `Idempotency-Key` header: it lets clients make a `POST` behave idempotently by having the server deduplicate on that key. Note this is a *contract*, not something HTTP enforces. Nothing stops you from writing a `GET` handler that deletes records — but caches, proxies, crawlers, and retry logic will all assume you didn't.
rep 3: 360 words
An HTTP method is **idempotent** if making the same request multiple times has the same effect on the server as making it once. The *responses* may differ, but the resulting server state doesn't change after the first successful application. **Idempotent methods:** GET, HEAD, OPTIONS, TRACE, PUT, DELETE **Not idempotent:** POST, PATCH ### Examples - `PUT /users/42` with a full body sets that user to a specific state. Send it five times, the user ends up in exactly that state — idempotent. - `DELETE /users/42` removes the user. The first call deletes it; subsequent calls find nothing to delete. State is the same either way — idempotent, even though the first returns `204` and later ones may return `404`. - `POST /users` creates a new user each time it's called. Five calls, five users — not idempotent. - `PATCH /counters/1` with `{"op": "increment"}` changes state every call — not idempotent. (A PATCH with an absolute value *could* be idempotent in practice, but the method isn't guaranteed to be.) ### Why it matters Idempotency is what makes **safe retries** possible. If a client sends a request and the connection drops before a response arrives, it doesn't know whether the server processed it. For an idempotent method, the client can just retry. This is why HTTP clients, proxies, and load balancers will automatically retry GET and PUT but generally won't retry POST. ### Related but distinct: "safe" A **safe** method doesn't modify state at all (GET, HEAD, OPTIONS, TRACE). Every safe method is idempotent, but not vice versa — PUT and DELETE are idempotent yet clearly modify state. ### Practical note Idempotency is a *contract* you're expected to honor, not something HTTP enforces. You can write a GET handler that charges a credit card — it just makes your API broken in ways clients won't expect, since something along the path may retry or prefetch it. When you genuinely need a non-idempotent operation to be retry-safe, the common pattern is an **idempotency key**: the client generates a unique ID per logical operation and sends it as a header (e.g. `Idempotency-Key: 7f3a...`). The server records the key with its result and returns the cached response on repeats instead of re-executing. Stripe's API is the canonical example of this.
brief
rep 1: 22 words
Making the same request multiple times has the same effect as making it once. GET, PUT, DELETE are idempotent. POST is not.
rep 2: 43 words
Making the same request multiple times has the same effect as making it once. GET, PUT, DELETE are idempotent. POST is not — repeat it and you create duplicates. Note: idempotent ≠ same response. `DELETE /users/5` returns 204 then 404, but server state is identical.
rep 3: 39 words
Making the same request multiple times has the same effect as making it once. GET, PUT, DELETE are idempotent; POST is not. Note: idempotent refers to server state, not necessarily identical responses (e.g. DELETE may return 204 then 404).

claude-opus-5-5

plain
rep 1: 286 words
An HTTP method is **idempotent** if making the same request once or many times leaves the server in the same state. The first request may change something, but repeating it has no further effect. ## Key points - **It's about server state, not the response.** Responses can differ between calls. For example, the first `DELETE /users/42` might return `200 OK` and the second `404 Not Found`, yet the method is still idempotent because the user is gone either way. - **Side effects like logging or metrics don't count.** Idempotency concerns the intended effect on the resource. - **Safe vs. idempotent:** A *safe* method doesn't modify state at all (it's read-only). Every safe method is idempotent, but not every idempotent method is safe. ## Standard methods (per RFC 9110) | Method | Safe | Idempotent | |---------|------|------------| | GET | ✅ | ✅ | | HEAD | ✅ | ✅ | | OPTIONS | ✅ | ✅ | | TRACE | ✅ | ✅ | | PUT | ❌ | ✅ | | DELETE | ❌ | ✅ | | POST | ❌ | ❌ | | PATCH | ❌ | ❌ (not guaranteed) | ## Examples - **PUT** `/users/42` with `{"name": "Alice"}` replaces the resource with that exact representation. Sending it 10 times gives the same result as sending it once. - **POST** `/orders` typically creates a new order each time. Sending it 10 times may create 10 orders. - **PATCH** depends on the operation. `{"name": "Alice"}` behaves idempotently, but `{"op": "increment", "field": "count"}` does not. ## Why it matters Networks are unreliable. If a request times out, the client can't tell whether the server processed it. With idempotent methods, clients, proxies, and libraries can **safely retry automatically**. With non-idempotent methods like POST, retrying risks duplicate actions such as double charges or duplicate orders. That's why many APIs (e.g., Stripe) support an **`Idempotency-Key` header**, which lets the server recognize and deduplicate retried POST requests. Idempotency is a *contract* defined by the spec. The server implementation must actually honor it. A poorly designed `GET` that modifies data breaks these guarantees.
rep 2: 354 words
An HTTP method is **idempotent** if making the same request multiple times has the same effect on the server as making it once. The key word is *effect*: the server's state ends up the same whether the request runs one time or ten times. ## Examples | Method | Idempotent? | Why | |---|---|---| | **GET** | ✅ Yes | Only reads data; nothing changes. | | **HEAD** | ✅ Yes | Like GET, but returns headers only. | | **OPTIONS** | ✅ Yes | Only asks what the server supports. | | **PUT** | ✅ Yes | Replaces a resource with the given content. Doing it again sets the same state. | | **DELETE** | ✅ Yes | After the first call the resource is gone. Later calls leave it gone. | | **POST** | ❌ No | Usually creates something new or triggers an action, so repeating it may create duplicates. | | **PATCH** | ❌ Not guaranteed | Depends on the patch. "Set name to Bob" is idempotent; "increment counter by 1" is not. | ## Important nuances - **The response can differ.** A first `DELETE /users/42` might return `200 OK` and a second `404 Not Found`. It's still idempotent because the server state (user 42 doesn't exist) is the same. - **Idempotent is not the same as safe.** A *safe* method doesn't modify state at all (GET, HEAD, OPTIONS). All safe methods are idempotent, but PUT and DELETE are idempotent without being safe. - **It describes intended semantics, not enforcement.** The HTTP spec (RFC 9110) defines these properties, but a badly designed server could still make a GET change data. Following the semantics is up to the API designer. - **Side effects like logging don't count.** A request can be logged or counted in analytics each time and still be idempotent. What matters is the resource state the client intended to change. ## Why it matters The main benefit is **safe retries**. If a network error happens and the client doesn't know whether the request succeeded: - With an idempotent method (PUT, DELETE), the client, proxy, or library can simply retry. - With POST, retrying might charge a credit card twice or create two orders. That's why many APIs, such as payment providers like Stripe, support an **`Idempotency-Key` header** on POST requests. The server remembers the key and ignores duplicates, which makes an otherwise non-idempotent operation safe to retry.
rep 3: 299 words
An HTTP method is **idempotent** if sending the same request once or many times leaves the server in the **same state**. The effect of N identical requests equals the effect of one. ## Key points - **It's about server state, not the response.** A repeated request can return a different status code or body and still be idempotent. For example, `DELETE /users/42` might return `200 OK` the first time and `404 Not Found` afterward, but the end state (user 42 is gone) is the same. - **It's a contract, not a guarantee.** The HTTP spec (RFC 9110) defines which methods *should* be idempotent. A badly designed API can still violate this. - **Side effects like logging don't count.** Only the intended effect on the resource matters. ## Which methods are idempotent | Method | Idempotent? | Why | |---|---|---| | `GET`, `HEAD`, `OPTIONS`, `TRACE` | ✅ Yes | Read-only ("safe"), so they change nothing | | `PUT` | ✅ Yes | Replaces the resource with the given state; repeating it sets the same state | | `DELETE` | ✅ Yes | Once deleted, it stays deleted | | `POST` | ❌ No | Typically creates something new each time (e.g., two orders) | | `PATCH` | ❌ Not necessarily | `{"name": "Bob"}` is idempotent, but "increment counter by 1" is not | ## Idempotent vs. safe - **Safe** means the method doesn't modify state at all (`GET`, `HEAD`, `OPTIONS`). - **Idempotent** means repeating it has no *additional* effect. - Every safe method is idempotent, but not every idempotent method is safe (`PUT` and `DELETE` change state). ## Why it matters Networks are unreliable. If a request times out, the client can't tell whether the server processed it. With idempotent methods, clients, proxies, and libraries can **safely retry** without causing duplicates. Retrying a `POST /payments`, by contrast, could charge someone twice. That's why many APIs, such as Stripe's, support an **`Idempotency-Key` header** on `POST` requests. The server remembers the key and returns the original result instead of repeating the operation.
brief
rep 1: 73 words
Making the same request once or many times leaves the server in the **same state**. - **Idempotent:** GET, HEAD, PUT, DELETE, OPTIONS, TRACE - **Not idempotent:** POST, PATCH (usually) Example: `DELETE /users/5` twice still just deletes user 5. `POST /users` twice may create two users. It's about server state, not responses: a second DELETE may return 404, but it's still idempotent. **Why it matters:** clients and proxies can safely retry idempotent requests after network failures.
rep 2: 77 words
Making the same request **multiple times has the same effect on the server as making it once**. - **Idempotent:** GET, PUT, DELETE, HEAD, OPTIONS - e.g., `DELETE /users/5` twice → user 5 is still just deleted - **Not idempotent:** POST (e.g., may create duplicate records), and PATCH (not guaranteed) **Note:** The *response* can differ (e.g., second DELETE returns 404); only the server state must be the same. **Why it matters:** Clients and proxies can safely retry idempotent requests after network failures.
rep 3: 66 words
Making the same request multiple times has the same effect on the server as making it once. - **Idempotent:** GET, HEAD, PUT, DELETE, OPTIONS, TRACE - **Not idempotent:** POST, and PATCH unless designed to be The effect is what must match, not the response. A second DELETE may return 404, but the resource is still gone. This matters because idempotent requests can be safely retried after network failures.
money-type: Should I store money amounts in PostgreSQL as float or as numeric?

Reference answer: Numeric.

claude-haiku-4-5

plain
rep 1: 179 words
# Use **NUMERIC** (or DECIMAL) for Money Amounts ## Short Answer Always use `NUMERIC` or `DECIMAL` in PostgreSQL for monetary values. Never use `float` or `double precision`. ## Why NUMERIC is Better ### Float Problems (Why NOT to use it) ```sql -- Floating-point precision issues SELECT 0.1::float + 0.2::float; -- Returns: 0.30000000000000004 (not 0.3!) SELECT (0.1::float + 0.2::float) = 0.3::float; -- Returns: false ``` These tiny rounding errors **accumulate** in financial systems and cause real problems. ### NUMERIC Advantages ```sql -- Perfect decimal precision SELECT 0.1::numeric + 0.2::numeric; -- Returns: 0.3 (correct!) SELECT (0.1::numeric + 0.2::numeric) = 0.3::numeric; -- Returns: true ``` ## Best Practice Definition ```sql -- Good: Specify precision and scale CREATE TABLE orders ( id SERIAL PRIMARY KEY, price NUMERIC(10, 2) -- 10 total digits, 2 decimal places ); -- Also fine: Without constraints (though less explicit) CREATE TABLE invoices ( id SERIAL PRIMARY KEY, amount NUMERIC -- No size limit ); ``` ## Why This Matters - **Accuracy**: No rounding errors accumulate - **Compliance**: Required for audits and financial regulations - **Trust**: Customers see exactly what they paid - **Performance**: The tiny speed difference is negligible for real-world applications **In summary**: `NUMERIC` is the industry standard for any monetary values. The small performance cost is worth the guaranteed correctness.
rep 2: 154 words
# Use `NUMERIC` (not `float`) for Money **Short answer:** Always use `NUMERIC` (or `DECIMAL`) for monetary amounts. ## Why NUMERIC is Better | Aspect | Float | Numeric | |--------|-------|---------| | **Accuracy** | ❌ Approximates values | ✅ Exact decimal storage | | **Rounding errors** | ❌ Accumulates errors | ✅ No rounding errors | | **Suitable for money** | ❌ No | ✅ Yes | ## The Problem with Float ```sql -- DON'T DO THIS CREATE TABLE orders ( id SERIAL PRIMARY KEY, amount FLOAT -- ❌ Bad for money! ); -- Floating-point arithmetic can produce unexpected results SELECT 0.1::float + 0.2::float; -- Might not equal exactly 0.3 ``` ## The Right Way ```sql -- DO THIS CREATE TABLE orders ( id SERIAL PRIMARY KEY, amount NUMERIC(10,2) -- ✅ Exactly 10 digits, 2 decimal places ); -- Safe for financial calculations SELECT 0.1::numeric + 0.2::numeric; -- Reliably equals 0.30 ``` ## PostgreSQL NUMERIC Specification ```sql NUMERIC(precision, scale) -- precision = total number of digits -- scale = digits after decimal point NUMERIC(10,2) -- Up to $99,999,999.99 NUMERIC(19,4) -- For cryptocurrency or very precise calculations NUMERIC -- Unlimited precision (slower, but available) ``` ## Best Practice Use `NUMERIC(10,2)` for standard currency, and adjust precision based on your actual needs.
rep 3: 174 words
# Use `NUMERIC` (or `DECIMAL`), Not `FLOAT` ## Why Not Float? **Floating-point types are unsuitable for money** because: 1. **Precision loss**: Binary floats can't exactly represent decimal values ```sql -- Example of the problem: SELECT 0.1::double precision + 0.2::double precision; -- Returns: 0.30000000000000004 ❌ ``` 2. **Accumulating errors**: Rounding errors compound through calculations, making audits unreliable 3. **Not designed for it**: Floats are meant for scientific calculations, not exact decimal representation ## The Right Choice: NUMERIC ```sql CREATE TABLE orders ( id SERIAL PRIMARY KEY, amount NUMERIC(10, 2), -- 10 digits total, 2 decimal places tax NUMERIC(10, 2), total NUMERIC(10, 2) ); ``` ### Key Benefits: - ✅ Exact decimal representation - ✅ No rounding errors - ✅ Arbitrary precision (you control it) - ✅ Industry standard for financial data - ✅ Minimal performance impact ## Specification Guide ```sql -- General format: NUMERIC(precision, scale) NUMERIC(10, 2) -- Max: 99,999,999.99 NUMERIC(19, 4) -- Max: 9,999,999,999,999.9999 NUMERIC(12, 2) -- Typical for most applications ``` - **Precision**: Total number of digits - **Scale**: Digits after decimal point ## TL;DR | Type | Use Case | Recommendation | |------|----------|---| | `NUMERIC` / `DECIMAL` | Money, financial data | ✅ **Use this** | | `DOUBLE PRECISION` / `REAL` | Scientific/approximate data | Avoid for money | Always use `NUMERIC` for anything involving money, prices, or financial calculations.
brief
rep 1: 39 words
**Use NUMERIC (or DECIMAL).** Float has precision issues with decimal arithmetic, causing rounding errors in financial calculations. NUMERIC stores exact decimal values and is the standard for money. Example: ```sql amount NUMERIC(10, 2) -- 10 total digits, 2 decimal places ```
rep 2: 33 words
**Use `NUMERIC` (or `DECIMAL`).** Float has rounding errors due to binary representation. Money requires exact decimal arithmetic, so numeric is essential to avoid precision loss. Example: `amount NUMERIC(10, 2)` for dollars with cents.
rep 3: 31 words
**Use `numeric`** Float has rounding errors from binary representation. Numeric stores exact decimal values, essential for money where precision matters. Example: ```sql price NUMERIC(10, 2) -- 10 total digits, 2 after decimal ```

gpt-5.6-terra

plain
rep 1: 88 words
Use `numeric` (or `decimal`), not `float`, for money. ```sql amount numeric(12,2) ``` `float` is binary floating-point, so values like `0.1` often cannot be represented exactly; this can cause rounding errors in balances and totals. For high-volume systems, another good pattern is storing the smallest unit as an integer: ```sql amount_cents bigint ``` Then `$12.34` is stored as `1234`. This is exact and fast, but you must handle currency scale explicitly (not every currency has two decimal places). Avoid PostgreSQL’s `money` type for most applications: it is locale-sensitive and less portable.
rep 2: 94 words
Use `numeric` (or `decimal`), not `float`, for money. ```sql amount numeric(12,2) NOT NULL ``` `float` is binary floating-point, so many decimal values cannot be represented exactly—leading to surprises such as rounding errors in totals or comparisons. For high-volume systems, another good option is an integer count of the smallest unit: ```sql amount_cents bigint NOT NULL ``` For example, store `$12.34` as `1234`. This is fast and exact, but requires application-side formatting and careful handling of currencies with different minor-unit rules. In short: - **Financial values:** `numeric(p, s)` or integer minor units. - **Measurements/approximate scientific data:** `double precision` / `float`.
rep 3: 114 words
Use `numeric` (or `decimal`), not `float`, for money. ```sql amount numeric(12,2) NOT NULL ``` `float` is binary floating-point, so values like `0.1` cannot be represented exactly. That can produce rounding artifacts and incorrect totals. For very high-volume systems, another good option is storing the smallest currency unit as an integer: ```sql amount_cents bigint NOT NULL ``` Then `1234` represents `$12.34`. This is especially useful when each value has a fixed scale (such as cents). Notes: - Choose precision/scale based on the currency and maximum amount. `numeric(12,2)` allows up to `9,999,999,999.99`. - Some currencies have 0 or 3 decimal places, so a single global `numeric(...,2)` may not fit every currency. - Store the ISO currency code separately (`USD`, `JPY`, etc.).
brief
rep 1: 21 words
Use `numeric`/`decimal`, not `float`. `float` introduces rounding errors; `numeric(12,2)` is exact for currency. Store minor units as `bigint` if performance matters.
rep 2: 18 words
Use `numeric`/`decimal`, never `float`, for money. Floats introduce rounding errors. Store the smallest unit as `bigint` when practical.
rep 3: 23 words
Use `numeric(p,s)`, not `float`. `float` introduces rounding errors; `numeric(12,2)` is exact for currency. Store minor units as `bigint` if you prefer integer cents.

claude-opus-5

plain
rep 1: 235 words
Use `numeric` (aka `decimal`) — never `float`/`double precision`. **Why:** floats are binary IEEE-754, so common decimal values like 0.10 aren't exactly representable. Errors accumulate over sums and comparisons: ```sql SELECT 0.1::float8 + 0.2::float8 = 0.3::float8; -- false SELECT 0.1::numeric + 0.2::numeric = 0.3::numeric; -- true ``` **Recommended definition:** ```sql amount numeric(19, 4) NOT NULL ``` - `numeric(p, s)` gives exact decimal arithmetic with enforced scale. - Scale 4 handles sub-cent values (interest, unit prices, FX). Use 2 only if you're certain you never need fractional cents. - Precision 19 is plenty for real-world totals; pick what fits your domain. - Store the currency separately (`char(3)` ISO-4217) — a bare amount is ambiguous. **Caveats with numeric:** - It's slower than float and variable-length. Irrelevant for typical OLTP; can matter in huge analytical aggregations. - Division still rounds: `1.00 / 3` isn't exact in *any* type. Decide rounding rules explicitly (`ROUND(x, 2)`) at the point where money is split or allocated, and make allocations sum back to the original. - `numeric` allows `NaN`. Add a check constraint if that matters: `CHECK (amount = amount)` or just `CHECK (amount >= 0)` where applicable. **The integer alternative:** storing minor units (cents) as `bigint` is also exact and fast, and is what many financial systems do. The tradeoff is that every read/write needs scaling, and you lose readable SQL. `numeric` is the better default unless you have a specific performance or interop reason. **Don't use `money`.** Its scale depends on the `lc_monetary` server setting, which makes it non-portable and surprising.
rep 2: 293 words
Use `numeric` — never `float` for money. **Why:** `float4`/`float8` are binary IEEE-754 floats, so values like 0.1 can't be represented exactly. Errors accumulate over sums and comparisons break: ```sql SELECT 0.1::float8 + 0.2::float8 = 0.3::float8; -- false SELECT 0.1::numeric + 0.2::numeric = 0.3::numeric; -- true ``` **What to use:** ```sql amount numeric(19, 4) NOT NULL ``` - `numeric` is exact decimal arithmetic — sums, rounding, and equality behave the way accountants expect. - Pick a scale that fits your domain: `2` for simple ledger balances, `4` (or more) if you deal with unit prices, FX rates, or interest where intermediate precision matters. - Precision `19` is a safe default; anything up to ~10^15 fits comfortably. **Caveats:** - `numeric` is slower than `float8` and stored as a variable-length value. This essentially never matters for transactional workloads. If you're doing heavy analytical aggregation over billions of rows, you can cast to `float8` for approximate reporting only. - Watch out for your driver/ORM silently mapping `numeric` to a float in the application layer. In Python use `decimal.Decimal` (psycopg does this by default); in Java use `BigDecimal`; in JS, `pg` returns numerics as strings by default — keep it that way and use a decimal library rather than `parseFloat`. - Always store the currency alongside the amount (`currency char(3)`), since scale and rounding rules differ per currency (JPY has 0 decimals, KWD has 3). **The alternative:** integer minor units — store cents as `bigint`. This is common in payment systems (Stripe does it) and is fast and unambiguous. The tradeoffs are that you must handle scaling everywhere in application code, and it's awkward for currencies with differing exponents or for sub-cent pricing. `numeric` is the better default unless you have a specific reason. **Avoid** the `money` type: its output format depends on the `lc_monetary` setting, it has fixed scale, and it has no currency awareness.
rep 3: 318 words
Use `numeric` — never `float`. **Why not float:** `float4`/`float8` are binary IEEE 754. Values like 0.1 have no exact binary representation, so errors accumulate: ```sql SELECT 0.1::float8 + 0.2::float8 = 0.3::float8; -- false SELECT SUM(x) FROM (VALUES (0.1::float8),(0.2),(0.3)) t(x); -- 0.6000000000000001 ``` That's fine for physics, fatal for ledgers that must balance to the cent. **The recommended column type:** ```sql amount numeric(19, 4) NOT NULL ``` `numeric` is exact base-10 arithmetic, so `0.1 + 0.2 = 0.3` exactly. Specifying precision/scale is worth doing: it enforces a constraint and stores more compactly than unconstrained `numeric`. Scale 4 rather than 2 gives room for tax rates, unit prices, and FX conversions without premature rounding — round to 2 only at presentation or settlement. **Always store the currency alongside it:** ```sql amount numeric(19,4) NOT NULL, currency char(3) NOT NULL -- ISO 4217 ``` A bare number is ambiguous, and you can't meaningfully sum mixed currencies. Note that scale 4 also handles currencies where the minor unit isn't 1/100 (JPY has 0 decimals, KWD has 3). **The alternative: integer minor units.** Store cents as `bigint`: ```sql amount_cents bigint NOT NULL ``` This is faster (native integer ops vs. numeric's variable-length software arithmetic) and is what Stripe and most payment APIs do on the wire. The tradeoffs: every read/write needs scaling, ad-hoc SQL is easier to misread, and you must decide upfront how many minor units — which gets awkward across currencies with different exponents. **Which to pick:** default to `numeric(19,4)` for application databases. Reach for `bigint` cents when you're at high transaction volume and have measured numeric arithmetic as a real bottleneck, or when you're mirroring a payment provider's representation exactly. **Client-side caveat:** make sure your driver doesn't silently convert `numeric` to a float and undo your work. In Python use `decimal.Decimal` (psycopg does this by default), in Java `BigDecimal`, in Go `shopspring/decimal` or a string scan. In JavaScript, `node-postgres` returns `numeric` as a *string* by default — parse it with a decimal library rather than `parseFloat`.
brief
rep 1: 30 words
`numeric` — exact decimal, no rounding errors. Float loses precision (0.1 + 0.2 ≠ 0.3). Use `numeric(19,4)` or similar. Alternative: store integer cents (`bigint`) if you want speed and full control over rounding.
rep 2: 21 words
`numeric` — exact decimal arithmetic. Floats introduce rounding errors that compound in sums. Use `numeric(19,4)` or similar. (Alternative: store cents as `bigint`.)
rep 3: 17 words
`numeric` — exact decimal, no rounding errors. Float loses cents. Use `numeric(19,4)` or store integer cents in `bigint`.

claude-opus-5-5

plain
rep 1: 274 words
**Use `numeric`, never `float`.** ## Why not float `real` and `double precision` are binary floating-point types. They can't represent most decimal fractions exactly, so rounding errors creep in: ```sql SELECT 0.1::float8 + 0.2::float8; -- 0.30000000000000004 SELECT 0.1::numeric + 0.2::numeric; -- 0.3 ``` With money, these errors accumulate across sums, splits, and interest calculations. Totals then fail to reconcile, and equality checks like `balance = 0` can fail unexpectedly. ## Use `numeric(p, s)` ```sql CREATE TABLE payments ( id bigserial PRIMARY KEY, amount numeric(19, 4) NOT NULL, currency char(3) NOT NULL -- ISO 4217, e.g. 'USD' ); ``` - `numeric` is exact decimal arithmetic. - `numeric(19,4)` is a common choice. The 4 decimal places leave room for intermediate calculations such as tax, FX rates, and per-unit pricing. Use `(12,2)` or similar if you only ever need cents. - Store the currency alongside the amount if you deal with more than one. ## Alternative: integer minor units Some systems store `bigint` cents (e.g., `1999` for $19.99). This is also exact and slightly faster. The tradeoffs: - You must know each currency's minor-unit exponent. JPY has 0, USD has 2, KWD has 3. - Sub-cent precision needs a different scale. - Conversion bugs happen at app boundaries. Both approaches are fine. `numeric` is simpler and less error-prone for most apps. ## Avoid the `money` type PostgreSQL's built-in `money` type is generally discouraged. Its behavior depends on the `lc_monetary` locale setting, it has fixed fractional precision, and it handles multiple currencies poorly. ## Don't forget the application side Make sure your application language doesn't convert amounts to floats. Use `Decimal` in Python, `BigDecimal` in Java, `decimal` in C#, or a decimal library like `decimal.js` or `dinero.js` in JavaScript, where database drivers often return `numeric` as strings for this reason.
rep 2: 253 words
Use **`numeric`** (also called `decimal`), not `float`. ## Why not float `real` and `double precision` are binary floating-point types. They can't represent most decimal fractions exactly, so rounding errors appear: ```sql SELECT 0.1::float8 + 0.2::float8; -- 0.30000000000000004 SELECT 0.1::numeric + 0.2::numeric; -- 0.3 ``` These errors accumulate in sums and comparisons. Totals end up off by a cent, and checks like `balance = 0` can fail unexpectedly. For money, that's unacceptable. ## Why numeric - **Exact decimal arithmetic.** No representation errors. - **Explicit precision and scale**, for example: ```sql amount numeric(12, 2) -- up to 9,999,999,999.99 ``` - **Rounding you control**, such as `round(x, 2)`. Tips: - Pick a scale that fits your domain. Use 2 for most currencies. Use more (e.g. 4 or higher) if you store unit prices, exchange rates, or interest calculations, or handle currencies with 3 decimal places like KWD or BHD. - Store the currency code in a separate column (`char(3)`, ISO 4217) if you deal with more than one currency. - Make sure your application reads the value into a decimal type (`BigDecimal`, Python `Decimal`, `decimal.js`, etc.), not a float. Otherwise you reintroduce the problem. ## Alternatives - **Integer minor units** (`bigint` storing cents): exact, fast, and common in payment systems like Stripe. The downside is that you must track each currency's scale yourself, and fractional-cent values are awkward. - **PostgreSQL's `money` type**: generally avoid it. Its formatting and behavior depend on the `lc_monetary` locale setting, it stores only one implicit currency, and it has fixed fractional precision. **Bottom line:** use `numeric(p, s)`, or `bigint` cents if you prefer integer math. Never use float for money.
rep 3: 312 words
**Use `numeric` (or integer minor units). Never `float`.** ## Why not float `real` and `double precision` are binary floating-point types. They can't represent most decimal fractions exactly, so errors creep in: ```sql SELECT 0.1::float8 + 0.2::float8; -- 0.30000000000000004 SELECT 0.1::float8 + 0.2::float8 = 0.3; -- false ``` These tiny errors accumulate across sums, rounding, and comparisons. Totals end up off by a cent, reconciliations fail, and equality checks break. With money, that's unacceptable. ## Option 1: `numeric(p, s)` (the usual choice) ```sql CREATE TABLE payments ( id bigserial PRIMARY KEY, amount numeric(19, 4) NOT NULL, currency char(3) NOT NULL -- ISO 4217, e.g. 'USD' ); ``` - Exact decimal arithmetic, so `0.1 + 0.2 = 0.3`. - `numeric(19,4)` is a common choice. The 4 decimal places leave room for intermediate calculations like tax, interest, and FX. Use `(12,2)` if you only ever need cents. - It's slower than integer math, but that almost never matters in practice. ## Option 2: integer minor units (`bigint`) Store cents (or the smallest unit) as a `bigint`: ```sql amount_cents bigint NOT NULL -- $12.34 stored as 1234 ``` - Fast, exact, and maps cleanly to most languages (this is Stripe's approach). - Downsides: you must track each currency's minor-unit scale (JPY has 0 decimals, KWD has 3), and it's awkward if you need sub-cent precision. ## Avoid the `money` type PostgreSQL has a built-in `money` type, but it's generally discouraged. Its formatting and parsing depend on the `lc_monetary` locale setting, it has fixed precision, and it doesn't store a currency. ## Other tips - **Store the currency** alongside the amount if you handle more than one. - **Keep it exact in your application too.** Use `Decimal` (Python), `BigDecimal` (Java), or a decimal library in JavaScript. Otherwise you lose the benefit by converting to float in code. - **Round explicitly** at defined points, and decide on a rounding mode (e.g. banker's rounding) as a business rule. **Bottom line:** default to `numeric`. Choose `bigint` cents if you want maximum performance and simplicity with standard currencies.
brief
rep 1: 34 words
**Numeric.** Floats can't represent many decimals exactly (e.g. `0.1 + 0.2 ≠ 0.3`), so rounding errors accumulate. ```sql amount numeric(12,2) ``` Alternative: store integer cents in `bigint`. Avoid PostgreSQL's `money` type, since it depends on locale settings.
rep 2: 37 words
**Numeric.** Floats are binary approximations, so `0.1 + 0.2 ≠ 0.3`, and rounding errors accumulate. Use `numeric(19,4)` or similar. Alternatively, store integer cents in a `bigint`. Avoid PostgreSQL's `money` type. It depends on locale and handles only one currency.
rep 3: 46 words
**Use `numeric`**, e.g. `numeric(12,2)`. It's exact decimal arithmetic. Float is binary and can't represent values like 0.1 exactly, so rounding errors accumulate in sums and comparisons. Alternative: store integer cents in `bigint`. It's fast and exact. Avoid PostgreSQL's `money` type, since its behavior depends on locale.

Report

How much the modifier "Be brief - use as few words as possible to express your thoughts." shortens answers to 10 concrete questions, and whether the answers stay right. Method, questions and checks are in ../README.md; the raw replies are in samples.jsonl, the isolation checks in isolation.jsonl.

Summary

Setup

Words per model

Sum over the 10 questions of the median words per cell. Call time is the median over all calls of the arm.

model plain brief brief / plain median call, plain → brief
Haiku 4.5 1331 277 0.21 6.0 s → 3.7 s
gpt-5.6-terra 501 121 0.24 5.9 s → 4.7 s
Opus 5 1402 144 0.10 5.3 s → 2.8 s
Opus 5.5 1693 267 0.16 5.2 s → 3.2 s

Words per question

Median words, plain → brief.

question kind Haiku 4.5 gpt-5.6-terra Opus 5 Opus 5.5
pg-port fact 51 → 1 5 → 1 1 → 1 28 → 1
git-undo-commit command 127 → 31 45 → 16 113 → 14 126 → 30
float-sum explanation 163 → 34 81 → 28 262 → 34 317 → 59
http-429 fact 94 → 22 5 → 4 33 → 4 64 → 4
docker-running command 130 → 18 12 → 3 10 → 8 101 → 8
tcp-vs-udp comparison 168 → 47 93 → 14 258 → 16 316 → 36
sort-stable yes/no 151 → 23 47 → 10 77 → 1 133 → 14
uptime-downtime calculation 74 → 15 21 → 4 39 → 6 35 → 5
idempotent definition 199 → 53 98 → 20 316 → 39 299 → 73
money-type recommendation 174 → 33 94 → 21 293 → 21 274 → 37

Sorted by how much the modifier cut, summed over the four models:

question kind plain brief brief / plain
pg-port fact 85 4 0.05
sort-stable yes/no 408 48 0.12
money-type recommendation 835 112 0.13
tcp-vs-udp comparison 835 113 0.14
docker-running command 253 37 0.15
http-429 fact 196 34 0.17
uptime-downtime calculation 169 30 0.18
float-sum explanation 823 155 0.19
idempotent definition 912 185 0.20
git-undo-commit command 411 91 0.22

Questions with a one-token answer (a number, yes/no, a single choice) shrink the most. Questions that invite a mechanism or a caveat (idempotent, float-sum, git-undo-commit) keep a fifth of their length: models still explain why, or add the pushed-commit warning.

What a brief reply keeps

Without the modifier a one-number question already shows each model's default: Opus 5 answers pg-port with "5432", terra with one sentence, Haiku 4.5 with a heading and two paragraphs (33–71 words).

Limits

Reproduce

deno task bench --models claude:claude-haiku-4-5,codex:gpt-5.6-terra,claude:claude-opus-5,claude:claude-opus-5-5 --reps 3
deno task report