@pipeworx/mcp-edge-case-museum 0.1.0 → 0.2.0

package/src/exhibits/float-money/nan-breaks-equality-and-max-min.json

@@ -1,70 +0,0 @@
-{
-  "id": "nan-breaks-equality-and-max-min",
-  "title": "NaN != NaN, and Python's max() picks a different \"largest\" value depending on where the NaN sits in the list",
-  "category": "float-money",
-  "assumption": "max() and min() over a list of numbers return the mathematically largest/smallest value, regardless of order, and a value always equals itself.",
-  "input": {
-    "display": "max([float('nan'), 1]) vs max([1, float('nan')])",
-    "description": "A price list, exchange-rate feed, or sensor reading where a bad or missing value has been coerced to NaN (e.g. a failed `float()` parse or a 0/0 division) and then run through max()/min() to find a best price."
-  },
-  "what_goes_wrong": "`float('nan') != float('nan')` is true (a NaN never equals even itself). Worse, Python's `max([nan, 1])` returns `nan`, but `max([1, nan])` - the same two values in the other order - returns `1`: whichever element happens to be compared against the running maximum first determines whether the NaN \"wins\". JavaScript's `Math.max` doesn't have this order sensitivity - it returns `NaN` regardless of where the NaN sits in the argument list.",
-  "why": "By IEEE 754, every comparison involving NaN (`<`, `>`, `<=`, `>=`, `==`) returns false. Python's built-in `max`/`min` are implemented as a linear scan that keeps a running best value and replaces it only when `candidate > running_best` is true; since any comparison against a NaN is false, the running best only changes to NaN if NaN happens to be the very first element compared (so it never gets replaced), but if NaN appears later, `nan > current_best` is false, so the NaN is skipped and the earlier value is kept. JavaScript's `Math.max` is specified to return NaN if any argument is NaN, checked independently of ordering, which is why it doesn't show the same asymmetry.",
-  "affects": [
-    "python",
-    "javascript"
-  ],
-  "repros": [
-    {
-      "language": "python",
-      "code": "nan = float(\"nan\")\nprint(nan != nan)\nprint(max([nan, 1]), max([1, nan]))\nprint(min([nan, 1]), min([1, nan]))\n",
-      "expected_output": "True\nnan 1\nnan 1",
-      "verified_with": "Python 3.14.2"
-    },
-    {
-      "language": "javascript",
-      "code": "console.log(NaN !== NaN);\nconsole.log(Math.max(NaN, 1), Math.max(1, NaN));\nconsole.log(Math.min(NaN, 1), Math.min(1, NaN));\n",
-      "expected_output": "true\nNaN NaN\nNaN NaN",
-      "verified_with": "Node.js v22.22.2"
-    }
-  ],
-  "fix": "Filter out NaN values before calling max()/min() (e.g. `math.isnan`/`Number.isNaN`), rather than relying on max/min to handle them - and never use `==`/`!=` to check for a missing or invalid price; test for NaN explicitly.",
-  "related": [],
-  "sources": [
-    {
-      "title": "Python docs: max()",
-      "url": "https://docs.python.org/3/library/functions.html#max"
-    },
-    {
-      "title": "MDN: Math.max()",
-      "url": "https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Math/max"
-    },
-    {
-      "title": "IEEE 754-2019 (comparison predicates involving NaN, summarized in Python's math module docs)",
-      "url": "https://docs.python.org/3/library/math.html#math.isnan"
-    }
-  ],
-  "tags": [
-    "money",
-    "price",
-    "accounting",
-    "comparison",
-    "validation",
-    "sorting"
-  ],
-  "test_cases": [
-    {
-      "inputs": [
-        [
-          "NaN",
-          "1"
-        ],
-        [
-          "1",
-          "NaN"
-        ]
-      ],
-      "relation": "equal",
-      "note": "A their_best_price(prices) function over price strings that may include an unparseable/NaN entry must give the same answer whatever order the list is in (filter or reject NaN explicitly); Python's max() over the floats gives nan for one order and 1.0 for the other."
-    }
-  ]
-}

package/src/exhibits/float-money/negative-zero-balance-formatting.json

@@ -1,74 +0,0 @@
-{
-  "id": "negative-zero-balance-formatting",
-  "title": "A $0.00 balance can print as \"-0.00\" - and Python and JavaScript disagree on when",
-  "category": "float-money",
-  "assumption": "A balance that computes to zero always displays as \"0.00\", regardless of how it was computed.",
-  "input": {
-    "display": "0.0 * -1, or -0.0, formatted as currency",
-    "description": "A zero balance that went through a multiplication or rounding with a negative operand: a zero quantity times a negative unit price (`0 * -4.99`), negating a zero balance (`-balance`), or rounding a tiny negative remainder to cents (`round(-0.004, 2)` in Python is -0.0). Note that plain subtraction to zero (`-5.0 + 5.0`) gives +0, not -0."
-  },
-  "what_goes_wrong": "Python's f\"{balance:.2f}\" on that zero prints \"-0.00\", showing a customer a balance that looks negative when it is exactly zero. JavaScript's `(balance).toFixed(2)` on the identical IEEE-754 value prints \"0.00\" - the sign silently disappears - and `JSON.stringify(balance)` serializes it as plain `0`. But JavaScript is not immune: a tiny negative amount such as -0.004 prints as \"-0.00\" from `toFixed(2)` in both languages.",
-  "why": "IEEE-754 doubles have two zeros, +0 and -0, which compare equal (`-0.0 == 0.0` and `-0 === 0` are both true) but are distinguishable (`Object.is(-0, 0)` is false, and `math.copysign(1, -0.0)` is -1.0). Python's float formatting renders the sign bit faithfully, so -0.0 becomes \"-0.00\". In ECMAScript, `toFixed` works on the mathematical value of the number, which for -0 is plain 0, and only emits \"-\" when that value is below zero - so -0 loses its sign but -0.004 keeps it and rounds to \"-0.00\". `JSON.stringify` goes through Number::toString, which the spec defines to return \"0\" for both zeros.",
-  "affects": [
-    "python",
-    "javascript"
-  ],
-  "repros": [
-    {
-      "language": "python",
-      "code": "import math\nbalance = 0.0 * -1\nprint(balance)\nprint(balance == 0.0)\nprint(f\"{balance:.2f}\")\nprint(math.copysign(1, balance))\nprint(f\"{balance:z.2f}\", f\"{-0.004:.2f}\", f\"{balance + 0:.2f}\")\n",
-      "expected_output": "-0.0\nTrue\n-0.00\n-1.0\n0.00 -0.00 0.00",
-      "verified_with": "Python 3.14.2"
-    },
-    {
-      "language": "javascript",
-      "code": "const balance = 0 * -1;\nconsole.log(balance);\nconsole.log(Object.is(balance, 0), balance === 0);\nconsole.log(balance.toFixed(2));\nconsole.log(JSON.stringify(balance));\nconsole.log((-0.004).toFixed(2), Object.is(balance + 0, 0));\n",
-      "expected_output": "-0\nfalse true\n0.00\n0\n-0.00 true",
-      "verified_with": "Node.js v22.22.2"
-    }
-  ],
-  "fix": "Normalize before display or serialization. Adding positive zero works in both languages (`balance + 0` turns -0 into +0 under IEEE-754 round-to-nearest), and Python 3.11+ has a dedicated format flag: `f\"{balance:z.2f}\"` prints \"0.00\" for -0.0 and for small negatives that round to zero. Better still for money, round to integer cents first (`Math.round(x * 100)` / `round(x * 100)`), then format the integer, and normalize `-0` cents to 0.",
-  "related": [
-    "splitting-100-dollars-three-ways-leaves-a-cent"
-  ],
-  "sources": [
-    {
-      "title": "IEEE 754-2019 (summary of signed zero via Python docs)",
-      "url": "https://docs.python.org/3/tutorial/floatingpoint.html"
-    },
-    {
-      "title": "MDN: Object.is()",
-      "url": "https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/is"
-    },
-    {
-      "title": "ECMA-262: Number::toString",
-      "url": "https://tc39.es/ecma262/#sec-numeric-types-number-tostring"
-    }
-  ],
-  "tags": [
-    "money",
-    "accounting",
-    "invoice",
-    "price",
-    "display",
-    "rounding"
-  ],
-  "test_cases": [
-    {
-      "inputs": [
-        0,
-        0
-      ],
-      "relation": "equal",
-      "note": "A balance-display function their_function(amount) should format 0.0 and -0.0 identically (both \"0.00\"), even though the underlying floats are distinguishable via Object.is / math.copysign."
-    },
-    {
-      "inputs": [
-        -0.004
-      ],
-      "relation": "returns",
-      "expected": "0.00",
-      "note": "A cents formatter given a tiny negative remainder that rounds to zero should show \"0.00\", not \"-0.00\" (both Python's .2f and JavaScript's toFixed(2) print \"-0.00\" here)."
-    }
-  ]
-}

package/src/exhibits/float-money/number-epsilon-false-positive-small-magnitude.json

@@ -1,52 +0,0 @@
-{
-  "id": "number-epsilon-false-positive-small-magnitude",
-  "title": "Number.EPSILON as a tolerance says 1e-20 and 2e-20 are equal, even though one is exactly double the other",
-  "category": "float-money",
-  "assumption": "Comparing `Math.abs(a - b) <= Number.EPSILON` is a safe, general-purpose \"close enough to be equal\" check for any two floating-point numbers.",
-  "input": {
-    "display": "Math.abs(1e-20 - 2e-20) <= Number.EPSILON",
-    "description": "A generic \"nearly equal\" helper copy-pasted into a pricing or rate-calculation codebase and applied to small fractional values (e.g. a per-unit rate, a tiny fee percentage, or a currency conversion remainder) as well as ordinary prices."
-  },
-  "what_goes_wrong": "`1e-20 !== 2e-20` correctly reports they're different numbers (one is literally double the other), but `Math.abs(1e-20 - 2e-20) <= Number.EPSILON` reports `true` - the \"nearly equal\" check says two values that differ by 100% of their own magnitude are equal.",
-  "why": "`Number.EPSILON` (about 2.22e-16) is the gap between 1 and the next representable double above it - it is an absolute tolerance calibrated for numbers near magnitude 1. For numbers much smaller than 1, that absolute tolerance is enormous relative to the values being compared, so genuinely different small numbers fall within it and are wrongly judged equal. (The mirror-image failure happens at large magnitudes: the gap between adjacent representable doubles grows past Number.EPSILON, so even values that are as close as floating point can represent are judged \"not equal\".) A tolerance has to scale with the magnitude of the numbers being compared - a fixed epsilon from the language's standard library does not do that for you.",
-  "affects": [
-    "javascript",
-    "python",
-    "any code using machine epsilon as an absolute tolerance"
-  ],
-  "repros": [
-    {
-      "language": "javascript",
-      "code": "const a = 1e-20;\nconst b = 2e-20;\nconsole.log(a === b);\nconsole.log(Math.abs(a - b), Number.EPSILON);\nconsole.log(Math.abs(a - b) <= Number.EPSILON);\n",
-      "expected_output": "false\n1e-20 2.220446049250313e-16\ntrue",
-      "verified_with": "Node.js v22.22.2"
-    },
-    {
-      "language": "python",
-      "code": "import sys\na = 1e-20\nb = 2e-20\nprint(a == b)\nprint(abs(a - b), sys.float_info.epsilon)\nprint(abs(a - b) <= sys.float_info.epsilon)\n",
-      "expected_output": "False\n1e-20 2.220446049250313e-16\nTrue",
-      "verified_with": "Python 3.14.2"
-    }
-  ],
-  "fix": "Use a tolerance that scales with the operands, e.g. `Math.abs(a - b) <= 1e-9 * Math.max(Math.abs(a), Math.abs(b))`, and add an absolute tolerance only if values near zero should count as equal in your domain. Python's `math.isclose(a, b)` does exactly this (relative `rel_tol=1e-09`, `abs_tol=0.0` by default) and returns False for 1e-20 vs 2e-20. Beware the common variant `Number.EPSILON * Math.max(|a|, |b|, 1)`: the `1` floor turns it back into an absolute EPSILON tolerance below magnitude 1, so it still calls 1e-20 and 2e-20 equal. For money, compare integer minor units instead of floats.",
-  "related": [
-    "float-anchor-0-1-plus-0-2"
-  ],
-  "sources": [
-    {
-      "title": "MDN: Number.EPSILON",
-      "url": "https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number/EPSILON"
-    },
-    {
-      "title": "Python docs: sys.float_info",
-      "url": "https://docs.python.org/3/library/sys.html#sys.float_info"
-    }
-  ],
-  "tags": [
-    "money",
-    "price",
-    "comparison",
-    "validation",
-    "accounting"
-  ]
-}

package/src/exhibits/float-money/parsefloat-comma-thousands-separator.json

@@ -1,66 +0,0 @@
-{
-  "id": "parsefloat-comma-thousands-separator",
-  "title": "parseFloat(\"1,234.56\") is 1 - not 1234.56, not NaN",
-  "category": "float-money",
-  "assumption": "parseFloat on a reasonable-looking number string either parses the whole number correctly or fails loudly.",
-  "input": {
-    "display": "parseFloat(\"1,234.56\")",
-    "description": "A price pasted from a spreadsheet, invoice, or a US-formatted input field (\"$1,234.56\") run through parseFloat to get a number."
-  },
-  "what_goes_wrong": "`parseFloat(\"1,234.56\")` returns `1` - it silently stops at the first character it can't parse (the comma) and returns whatever valid number prefix it found, rather than parsing the full value or raising an error.",
-  "why": "JavaScript's `parseFloat` is specified to skip leading whitespace, consume the longest prefix of the string that is valid decimal-literal syntax, and return that - it never looks at (or errors on) what comes after. A comma is not part of that syntax, so parsing stops right after the leading \"1\" and \",234.56\" is silently discarded. A leading \"$\" is not number syntax either, so `parseFloat(\"$1,234.56\")` finds no valid prefix at all and returns NaN. `Number()` is stricter - it requires the whole string to be numeric - so it returns NaN for both.",
-  "affects": [
-    "javascript"
-  ],
-  "repros": [
-    {
-      "language": "javascript",
-      "code": "console.log(parseFloat(\"1,234.56\"));\nconsole.log(parseFloat(\"$1,234.56\"));\nconsole.log(Number(\"1,234.56\"));\n",
-      "expected_output": "1\nNaN\nNaN",
-      "verified_with": "Node.js v22.22.2"
-    },
-    {
-      "language": "python",
-      "code": "try:\n    print(float(\"1,234.56\"))\nexcept ValueError as e:\n    print(\"ValueError:\", e)\n",
-      "expected_output": "ValueError: could not convert string to float: '1,234.56'",
-      "verified_with": "Python 3.14.2"
-    }
-  ],
-  "fix": "Never feed locale-formatted user input straight into parseFloat/float(). Strip grouping separators explicitly (knowing which character is the grouping separator for the input's locale) before parsing, or use a locale-aware parser (e.g. derive the separators from `Intl.NumberFormat(locale).formatToParts(1234.5)` in JS) rather than a generic numeric parser.",
-  "related": [
-    "intl-number-format-de-de-roundtrip-misparsed"
-  ],
-  "sources": [
-    {
-      "title": "MDN: parseFloat()",
-      "url": "https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/parseFloat"
-    },
-    {
-      "title": "ECMA-262: parseFloat",
-      "url": "https://tc39.es/ecma262/#sec-parsefloat-string"
-    },
-    {
-      "title": "Python docs: float()",
-      "url": "https://docs.python.org/3/library/functions.html#float"
-    }
-  ],
-  "tags": [
-    "money",
-    "price",
-    "invoice",
-    "currency",
-    "i18n",
-    "validation",
-    "forms"
-  ],
-  "test_cases": [
-    {
-      "inputs": [
-        "1,234.56"
-      ],
-      "relation": "returns",
-      "expected": 1234.56,
-      "note": "A their_parse_price(input) function given US-formatted \"1,234.56\" should return 1234.56, not silently truncate to 1 like raw parseFloat/Number does."
-    }
-  ]
-}

package/src/exhibits/float-money/python-banker-rounding-vs-js-round-half-up.json

@@ -1,65 +0,0 @@
-{
-  "id": "python-banker-rounding-vs-js-round-half-up",
-  "title": "round(2.5) is 2 in Python but Math.round(2.5) is 3 in JavaScript",
-  "category": "float-money",
-  "assumption": "Rounding a value that is exactly halfway between two integers always rounds up, in every language.",
-  "input": {
-    "display": "round(2.5) in Python 3 vs Math.round(2.5) in JavaScript, and round(-2.5) vs Math.round(-2.5)",
-    "description": "A genuine tie - e.g. rounding a $2.50 half-unit quantity, or a tax amount that lands exactly on a half-cent after an earlier exact calculation - rounded to the nearest whole unit."
-  },
-  "what_goes_wrong": "The exact same halfway value rounds to a different integer depending on the language: Python's round(2.5) is 2 and round(3.5) is 4 (always to the nearest even integer), while JavaScript's Math.round(2.5) is 3 (always rounds .5 up, toward positive infinity) - and Math.round(-2.5) is -2, not -3, because \"up\" for Math.round means toward +Infinity even on the negative side.",
-  "why": "Python 3's round() implements round-half-to-even (\"banker's rounding\", IEEE 754's default rounding mode) specifically to avoid statistical bias from always rounding .5 the same direction over many values. JavaScript's Math.round() is specified (ECMA-262) to round half-way cases toward +Infinity, not away from zero and not to even - which is why -2.5 rounds to -2 (toward +Infinity means less negative) rather than -3. Neither behavior is a bug; they are different, deliberately documented rounding rules, and porting rounding logic between the two languages without accounting for the difference changes answers for every exact half.",
-  "affects": [
-    "python",
-    "javascript"
-  ],
-  "repros": [
-    {
-      "language": "python",
-      "code": "print(round(2.5), round(3.5), round(-2.5), round(-3.5))\n",
-      "expected_output": "2 4 -2 -4",
-      "verified_with": "Python 3.14.2"
-    },
-    {
-      "language": "javascript",
-      "code": "console.log(Math.round(2.5), Math.round(3.5), Math.round(-2.5), Math.round(-3.5));\n",
-      "expected_output": "3 4 -2 -3",
-      "verified_with": "Node.js v22.22.2"
-    }
-  ],
-  "fix": "Decide and document one rounding rule for money (customer-facing amounts commonly use round-half-up, away from zero; some accounting contexts deliberately use half-even) and implement it explicitly - e.g. Python's decimal.Decimal.quantize(..., rounding=decimal.ROUND_HALF_UP) - rather than relying on whatever a language's built-in round happens to do.",
-  "related": [
-    "python-round-2-675-float-imprecision",
-    "decimal-from-float-vs-string"
-  ],
-  "sources": [
-    {
-      "title": "Python docs: round()",
-      "url": "https://docs.python.org/3/library/functions.html#round"
-    },
-    {
-      "title": "MDN: Math.round()",
-      "url": "https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Math/round"
-    },
-    {
-      "title": "ECMA-262: Math.round",
-      "url": "https://tc39.es/ecma262/#sec-math.round"
-    }
-  ],
-  "tags": [
-    "money",
-    "rounding",
-    "price",
-    "accounting",
-    "invoice"
-  ],
-  "test_cases": [
-    {
-      "inputs": [
-        2.5
-      ],
-      "relation": "no_crash",
-      "note": "A cross-language rounding function should not assume their_function(2.5) gives the same result as Math.round(2.5) in JS (3) or round(2.5) in Python (2) by default - pick one explicit rule and implement it the same way everywhere."
-    }
-  ]
-}

package/src/exhibits/float-money/python-round-2-675-float-imprecision.json

@@ -1,64 +0,0 @@
-{
-  "id": "python-round-2-675-float-imprecision",
-  "title": "round(2.675, 2) is 2.67 in Python, not 2.68",
-  "category": "float-money",
-  "assumption": "round(x, 2) rounds a price to the nearest cent the way a calculator would, based on the decimal digits you wrote.",
-  "input": {
-    "display": "round(2.675, 2)",
-    "description": "Rounding a unit price quoted to three decimals, such as $2.675 from a supplier price list or a per-unit rate table, to the nearest cent before storing or displaying it."
-  },
-  "what_goes_wrong": "`round(2.675, 2)` returns 2.67, not 2.68, even though 2.675 looks exactly halfway between 2.67 and 2.68.",
-  "why": "The literal 2.675 is not exactly representable in IEEE-754 double; the nearest representable double is approximately 2.67499999999999982236..., which is strictly below the true halfway point. Python's round() rounds that actual stored value, so it correctly rounds down to 2.67 - the \"error\" is in the input's binary representation, not in round()'s rounding rule. This is the same mechanism as JavaScript's toFixed surprises, and it is independent of Python's round-half-to-even tie-breaking rule, because 2.67499999999999982236... isn't a tie to begin with.",
-  "affects": [
-    "python",
-    "any IEEE-754 double rounded by value rather than by decimal text"
-  ],
-  "repros": [
-    {
-      "language": "python",
-      "code": "x = 2.675\nprint(round(x, 2))\nprint(f\"{x:.20f}\")\nimport decimal\nprint(decimal.Decimal(x))\n",
-      "expected_output": "2.67\n2.67499999999999982236\n2.67499999999999982236431605997495353221893310546875",
-      "verified_with": "Python 3.14.2"
-    },
-    {
-      "language": "javascript",
-      "code": "const x = 2.675;\nconsole.log(Number(x.toFixed(2)));\nconsole.log(x.toFixed(20));\n",
-      "expected_output": "2.67\n2.67499999999999982236",
-      "verified_with": "Node.js v22.22.2"
-    }
-  ],
-  "fix": "Build the number from a decimal string with decimal.Decimal(\"2.675\") instead of a float literal, and round that - Decimal preserves the exact decimal value, so round-half-even on it gives the answer a human expects. Or round integer cents directly, never a float dollar amount.",
-  "related": [
-    "tofixed-1-005-rounds-down-not-up",
-    "python-banker-rounding-vs-js-round-half-up",
-    "decimal-from-float-vs-string"
-  ],
-  "sources": [
-    {
-      "title": "Python docs: round()",
-      "url": "https://docs.python.org/3/library/functions.html#round"
-    },
-    {
-      "title": "Python docs: 15.1. Floating-Point Arithmetic: Issues and Limitations",
-      "url": "https://docs.python.org/3/tutorial/floatingpoint.html"
-    }
-  ],
-  "tags": [
-    "money",
-    "rounding",
-    "price",
-    "currency",
-    "invoice",
-    "accounting"
-  ],
-  "test_cases": [
-    {
-      "inputs": [
-        "2.675"
-      ],
-      "relation": "returns",
-      "expected": "2.68",
-      "note": "A price-rounding function given the exact decimal string \"2.675\" should round to \"2.68\" (round-half-up on the true decimal value); round(float(\"2.675\"), 2) in Python returns 2.67 instead."
-    }
-  ]
-}

package/src/exhibits/float-money/splitting-100-dollars-three-ways-leaves-a-cent.json

@@ -1,63 +0,0 @@
-{
-  "id": "splitting-100-dollars-three-ways-leaves-a-cent",
-  "title": "Splitting $100.00 three ways and rounding each share loses a cent",
-  "category": "float-money",
-  "assumption": "Dividing a total into N equal shares and rounding each share to the nearest cent reconstructs the original total when you add the shares back up.",
-  "input": {
-    "display": "10000 cents / 3, rounded, times 3",
-    "description": "Splitting a bill, a refund, or a revenue share three ways (or any way that doesn't divide evenly) and charging/crediting each party its rounded share."
-  },
-  "what_goes_wrong": "$100.00 split three ways gives 3333.33... cents per share; rounding each share to 3333 cents and charging three people that amount collects only $99.99 in total - one cent has vanished, and nobody's individual charge was wrong in isolation.",
-  "why": "10000 / 3 is not an integer, so any rounding of the per-share amount (3333.333... -> 3333) discards a fractional remainder. Doing that independently for each of the three shares discards the remainder three times instead of accounting for it once, so the sum of the rounded shares no longer equals the original total. This isn't a floating-point bug - it happens with exact integer-cent arithmetic too - it's a remainder-allocation bug: dividing a fixed amount into N parts leaves `total mod N` leftover units (here 1 cent) that something has to explicitly absorb.",
-  "affects": [
-    "python",
-    "javascript",
-    "any integer or float division used to split a shared amount"
-  ],
-  "repros": [
-    {
-      "language": "python",
-      "code": "total_cents = 10000\nn = 3\nshare = round(total_cents / n)\nprint(share, share * n, total_cents - share * n)\n",
-      "expected_output": "3333 9999 1",
-      "verified_with": "Python 3.14.2"
-    },
-    {
-      "language": "javascript",
-      "code": "const totalCents = 10000;\nconst n = 3;\nconst share = Math.round(totalCents / n);\nconsole.log(share, share * n, totalCents - share * n);\n",
-      "expected_output": "3333 9999 1",
-      "verified_with": "Node.js v22.22.2"
-    }
-  ],
-  "fix": "Work in integer cents and allocate the remainder explicitly: every share gets `total // n`, and the first `total % n` shares get one extra cent (10000 split 3 ways -> [3334, 3333, 3333]). The shares then always sum to the exact original total and differ by at most one cent; which recipients get the extra cents is a product decision, but something must hand them out deliberately.",
-  "related": [
-    "negative-zero-balance-formatting"
-  ],
-  "sources": [
-    {
-      "title": "Python docs: 15.1. Floating-Point Arithmetic: Issues and Limitations",
-      "url": "https://docs.python.org/3/tutorial/floatingpoint.html"
-    }
-  ],
-  "tags": [
-    "money",
-    "rounding",
-    "accounting",
-    "invoice",
-    "price"
-  ],
-  "test_cases": [
-    {
-      "inputs": [
-        10000,
-        3
-      ],
-      "relation": "returns",
-      "expected": [
-        3334,
-        3333,
-        3333
-      ],
-      "note": "A splitting function their_function(totalCents, n) should return shares that sum to exactly totalCents - e.g. [3334, 3333, 3333], not three independently-rounded 3333s that sum to 9999."
-    }
-  ]
-}

package/src/exhibits/float-money/sum-ten-dimes-not-a-dollar.json

@@ -1,77 +0,0 @@
-{
-  "id": "sum-ten-dimes-not-a-dollar",
-  "title": "Ten 0.1s added in a loop don't equal 1 - but since Python 3.12, sum() gives exactly 1.0 and the loop still doesn't",
-  "category": "float-money",
-  "assumption": "Accumulating ten $0.10 charges one at a time gives exactly $1.00, and Python's sum() is just a loop in disguise.",
-  "input": {
-    "display": "a loop adding 0.1 ten times, vs. sum([0.1] * 10)",
-    "description": "A running total built up line-by-line as items are scanned or charges applied, e.g. ten $0.10 surcharges added to an order as it is built."
-  },
-  "what_goes_wrong": "A hand-written accumulator (`total += 0.1` ten times) ends at 0.9999999999999999, not 1.0, in both Python and JavaScript - but on Python 3.12 and later the built-in `sum([0.1]*10)` prints exactly 1.0 (on 3.11 and earlier it printed 0.9999999999999999, same as the loop), so swapping a loop for `sum()`, or upgrading Python, silently changes the answer.",
-  "why": "Each addition rounds to the nearest representable double, and those small rounding errors compound across ten sequential additions, landing one ULP below 1.0. In Python 3.12, CPython's built-in `sum()` switched to compensated (Neumaier) summation for floats: it carries the rounding error of each addition in a separate correction term and adds it back at the end, so for this input it no longer reproduces the naive loop's error. It is not the same as `math.fsum` (which is exactly rounded for every input); the docs only promise \"higher accuracy and better commutativity on most builds\". JavaScript has no built-in equivalent in Node 22 - `reduce` and a hand-rolled loop behave identically because both are plain sequential addition.",
-  "affects": [
-    "python",
-    "javascript"
-  ],
-  "repros": [
-    {
-      "language": "python",
-      "code": "total = 0.0\nfor _ in range(10):\n    total += 0.1\nprint(total, total == 1.0)\nprint(sum([0.1] * 10), sum([0.1] * 10) == 1.0)\n",
-      "expected_output": "0.9999999999999999 False\n1.0 True",
-      "verified_with": "Python 3.14.2"
-    },
-    {
-      "language": "javascript",
-      "code": "let total = 0;\nfor (let i = 0; i < 10; i++) { total += 0.1; }\nconsole.log(total, total === 1);\nconst reduced = [0.1,0.1,0.1,0.1,0.1,0.1,0.1,0.1,0.1,0.1].reduce((a, b) => a + b, 0);\nconsole.log(reduced, reduced === 1);\n",
-      "expected_output": "0.9999999999999999 false\n0.9999999999999999 false",
-      "verified_with": "Node.js v22.22.2"
-    }
-  ],
-  "fix": "Do the running total in integer minor units (cents) or with a Decimal type, not floating-point dollars. Don't rely on `sum()` happening to be more accurate than a loop in a particular Python version - that's an implementation detail, not a guarantee for every float computation.",
-  "related": [
-    "float-anchor-0-1-plus-0-2",
-    "naive-loop-sum-order-dependence"
-  ],
-  "sources": [
-    {
-      "title": "Python docs: sum()",
-      "url": "https://docs.python.org/3/library/functions.html#sum"
-    },
-    {
-      "title": "What's New In Python 3.12",
-      "url": "https://docs.python.org/3/whatsnew/3.12.html"
-    },
-    {
-      "title": "Python docs: 15.1. Floating-Point Arithmetic: Issues and Limitations",
-      "url": "https://docs.python.org/3/tutorial/floatingpoint.html"
-    }
-  ],
-  "tags": [
-    "money",
-    "rounding",
-    "currency",
-    "accounting",
-    "price",
-    "invoice"
-  ],
-  "test_cases": [
-    {
-      "inputs": [
-        [
-          0.1,
-          0.1,
-          0.1,
-          0.1,
-          0.1,
-          0.1,
-          0.1,
-          0.1,
-          0.1,
-          0.1
-        ]
-      ],
-      "relation": "no_crash",
-      "note": "A totaling function should not assume their_function(ten dimes) == 1.0 unless it works in integer cents or Decimal; don't trust that it happens to round correctly on today's runtime."
-    }
-  ]
-}

package/src/exhibits/float-money/tofixed-1-005-rounds-down-not-up.json

@@ -1,63 +0,0 @@
-{
-  "id": "tofixed-1-005-rounds-down-not-up",
-  "title": "(1.005).toFixed(2) is \"1.00\", not \"1.01\"",
-  "category": "float-money",
-  "assumption": "toFixed(2) rounds a price to the nearest cent using ordinary round-half-up rules.",
-  "input": {
-    "display": "(1.005).toFixed(2)",
-    "description": "Rounding a computed price like $1.005 (e.g. a $1 item with a 0.5% fee) to two decimal places for display or for a ledger entry."
-  },
-  "what_goes_wrong": "`(1.005).toFixed(2)` returns the string \"1.00\" - the price appears to round down even though 1.005 is exactly halfway between 1.00 and 1.01.",
-  "why": "The literal 1.005 cannot be represented exactly in IEEE-754 double; the nearest representable double is approximately 1.00499999999999989341..., which is already below 1.005. `toFixed` rounds that true underlying value, not the digits you typed, so it correctly rounds 1.00499999... down to \"1.00\". The bug isn't in toFixed's rounding rule - it's that the number was never exactly 1.005 to begin with.",
-  "affects": [
-    "javascript",
-    "any IEEE-754 double formatted by rounding its true binary value"
-  ],
-  "repros": [
-    {
-      "language": "javascript",
-      "code": "console.log((1.005).toFixed(2));\nconsole.log((1.005).toFixed(20));\n",
-      "expected_output": "1.00\n1.00499999999999989342",
-      "verified_with": "Node.js v22.22.2"
-    },
-    {
-      "language": "python",
-      "code": "x = 1.005\nprint(f\"{x:.2f}\")\nprint(f\"{x:.20f}\")\n",
-      "expected_output": "1.00\n1.00499999999999989342",
-      "verified_with": "Python 3.14.2"
-    }
-  ],
-  "fix": "Don't round a float's decimal string representation and expect it to match the decimal literal you wrote. Work in integer minor units (round the amount to cents as an integer before any division back to dollars) or use a Decimal type constructed from a string, not a float literal.",
-  "related": [
-    "tofixed-2-345-inconsistent-rounding",
-    "python-round-2-675-float-imprecision",
-    "decimal-from-float-vs-string"
-  ],
-  "sources": [
-    {
-      "title": "ECMA-262: Number.prototype.toFixed",
-      "url": "https://tc39.es/ecma262/#sec-number.prototype.tofixed"
-    },
-    {
-      "title": "Python docs: 15.1. Floating-Point Arithmetic: Issues and Limitations",
-      "url": "https://docs.python.org/3/tutorial/floatingpoint.html"
-    }
-  ],
-  "tags": [
-    "money",
-    "rounding",
-    "price",
-    "currency",
-    "invoice",
-    "display"
-  ],
-  "test_cases": [
-    {
-      "inputs": [
-        1.005
-      ],
-      "relation": "no_crash",
-      "note": "A price-rounding function should not assume their_function(1.005) == 1.01 by formatting the float's decimal digits; it should round an exact (integer-cents or Decimal) representation."
-    }
-  ]
-}