Methodology

Everything here rests on one fact: the expected cost of gambling is the amount staked multiplied by the house edge. Formally, with predetermined turnover T held fixed, expected value is linear in T, which follows from the linearity of expectation and holds no matter how that wagering is divided into individual bets.

That last point does real work. It means that with T held fixed, bet sizing does not change the expected total loss — staking 500 SC as five hundred 1 SC bets or as one hundred 5 SC bets gives the same average. Bet size changes only how widely results scatter around that average. Any claim that a particular staking pattern improves expected return is wrong, and this site will not make one.

The formula above assumes the full requirement gets staked. In reality wagering often stops when the balance runs out, so the true expectation is B − h × E[actual turnover]. If every stake is at most the remaining requirement, actual turnover is at most T and B − T × h is a lower bound. The published simulator, however, always stakes a full last bet, so actual turnover can exceed T by up to one stake. With that overshoot the bound is directional rather than a theorem under the simulator.

The gap is typically small relative to one stake when the balance comfortably covers the requirement, and it grows as busting becomes likely. You can see it directly: run the variance explorer with a heavy requirement and the simulated mean sits above the closed-form figure, because runs that empty their balance stop losing while the formula keeps staking past zero.

The alternative was to model ruin exactly. That requires the game’s full payout distribution and the bet size, and produces an answer only for a specific game whose paytable is published — which is almost never. A stated lower bound with its assumption named is more honest than a precise-looking number derived from a paytable we invented.

When T × h reaches or exceeds B, the arithmetic gives a negative balance. A balance cannot be negative, and printing “−25 SC” would present a broken assumption as a result. The calculators stop there and say what broke.

This is enforced in the code rather than left to discipline. The calculation returns a different type in that state — one that has no expected-balance field at all — so no part of the site is able to display a negative expected balance even by mistake.

In the same state, the site reports the break-even multiplier m* = c ÷ h and says plainly that completing the requirement would take an above-average result, without offering a probability. Calculating that probability needs the payout distribution, which is not an input here.

Currency and Sweeps Coin values are held as exact decimals rather than binary floating point, so 0.1 + 0.2 is 0.3. This matters because the site publishes cost-per-coin ratios derived from small decimal amounts, and repeated rounding through a chain of operations is how a calculator quietly accumulates error. Deterministic calculators compute at 28 decimal places of working precision and round for display. The variance simulation uses ordinary floating-point arithmetic. Stored roulette figures are four-decimal presentations of exact fractions.

The variance simulation is the exception: it runs in ordinary floating point, because its output is the shape of a distribution rather than a published figure, and its percentiles are sample estimates anyway. They are shown to the nearest whole coin for that reason.

Input parsing rejects rather than guesses. A value like “1,23” could be one and twenty-three hundredths or one hundred and twenty-three, and no amount of cleverness resolves it from the string alone — so the calculator asks rather than choosing. The same applies to more decimal places than a field can carry: entering a price of “19.999” is rejected rather than silently rounded, because the rounding would be invisible in the result.