The low-memory engine

An opt-in solver engine that stores its accumulators at half precision. It roughly halves the memory a solve needs — on a big flop tree, about 19GB becomes about 10GB, which is the difference between solving it and not on a 16GB machine.

It is off by default, and it should stay off unless you need it. This page is mostly about why.

What it costs, exactly

Not accuracy. Precision.

The distinction sounds like hair-splitting and isn't. Against the normal engine, the low-memory engine produces expected values matching to within 0.002 chips, identical deltas when checked against PioSolver, and the same preferred action on 100% of reach. It is not computing a different answer, or a worse one. It arrives in the same place.

What it can't do is pin down the mix as finely. A flop solve settles around 0.79% of pot from perfect — 0.432 chips on a 55-chip pot — where the normal engine reaches 0.5%. So the strategy it hands you is correctly centred but coarsely resolved: right about which action, less exact about how often.

The numbers

Two footnotes on those, because both are easy to quote wrong. The memory saving is exactly 50% of accumulator bytes; smaller trees show a smaller percentage only because a fixed ~150MB of overhead dilutes it, which is not the figure that matters for the trees this exists to make possible. And the precision number is at flop scale deliberately — the river floor is far tighter, and irrelevant, because flop spots are what people actually run.

What it will not let you do

These are not warnings. They're refusals — the product declines rather than handing you a number it can't stand behind. Both are enforced, in different places: one by the app, one by the rules pipeline itself, so neither depends on you remembering which engine you left switched on.

It stops at its floor

Past the point where it has extracted what half precision can represent, more iterations make the result worse, not better: measured at 0.4566, then 0.3767, then 0.6518 at 100, 300 and 600 steps. An unguarded version of this engine would quietly reward patience with a worse strategy. This one detects its floor, stops, and tells you it stopped.

Node locking is refused

Locking a node and re-solving is the one thing this engine genuinely cannot do. Re-converging after a lock stalls at 0.4886 where the normal engine reaches 0.001 — off by a factor of hundreds. Attempting it returns an error rather than a result.

Rule pricing is refused

Pricing a mined rule works by disabling an action and re-solving to measure what the restriction costs — the same mid-solve shock as a lock. On this engine the masked solve misses the true restricted tree by 0.548 on a 100-chip pot, so the price would be wrong by more than most rules cost.

The pricer asks the engine what precision it's running at and refuses outright if the answer isn't full precision, rather than trusting the app's own setting. A rules package is a durable artifact that outlives the session that produced it, so a wrong price in one is worth refusing loudly.

When to use it

One case: a tree you want to solve doesn't fit in your machine's memory. That's it. If the tree fits, the normal engine gives you a better strategy for the same wall-clock time, since the speed is a wash.

It's a good trade for exploring a big tree's shape, checking EVs, and answering "which action here". It's the wrong tool for reading exact mixing frequencies off a solve, and the product blocks the two workflows where it would actively mislead you.

Turning it on

Settings → the low-memory engine toggle. It only appears if a low-memory build is installed — an option you can't take is just a question you can't answer. Turning it on asks you to confirm once, with the same trade-off summarized; turning it off is a return to the default and asks nothing.