{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreihn7lhc2vgfcau6ysulny3wk5tue45ugwnd6igkxsqr5z5oxmqou4",
    "uri": "at://did:plc:pi6woz4d47bkuws673w2il2r/app.bsky.feed.post/3miw7pbzx5kw2"
  },
  "path": "/t/why-not-use-smallcheck/13860?page=2#post_21",
  "publishedAt": "2026-04-07T15:16:08.000Z",
  "site": "https://discourse.haskell.org",
  "textContent": "turion:\n\n> For your specific example, for a threshold of 18, `tinycheck` finds the bug after less than 2 million (and more than 200 000) values, which takes 0.3 seconds on my machine.\n\nHah, I wanted to write a comment here about how the enumeration could order the candidates based on the sum of all the integers in the list (e.g. `[1,1]` would come immediately after or before `[2]`). But then you’re still generating an exponential amount of tests. It turns out that 18 is still kind of reachable at 131.072 tests before you reach `replicate 18 1`. However, it takes _much_ more tests before you get to any kind of representative array of 18 numbers. With every value of the sum you add, the number of tests required doubles. I’m guessing you were lucky that the bug appeared for an array with 17 zeroes and a single one (or something like that), which would “only” require between 262.144 and 524.288 tests.\n\n* * *\n\nThinking about it again, maybe you could do much better if you made and ordering based on merging different orders of magnitude. Consider generating tests for a single integer. We could consider the ranges 1-10, 10-100, 100-1000, etc. separately and then merge their orders. So you’d get 0, 1, 10, 100, …, 1, 11, 101, …, 2, 12, 102, …\nFor lists (or vectors) you’d first test length 1, then length 10, then 100, etc.\n\nI guess one problem will be that the larger lists will take much longer to tests, so maybe we want to bias this more to the smaller lists. Also, this means we would probably want shrinking again.",
  "title": "Why not use smallcheck?"
}