heuristic-excess

At its defaults it draws two greedy contraction rules against the exhaustive optimum, over 60 random networks. Each curve is one rule's excess over the exhaustive answer, sorted, so the horizontal axis is the share of networks at or below that excess. Pairing whichever two operands are cheapest to multiply is optimal on 1.7 per cent of them, has a median excess of 1.446 and a worst case of 25.4. Pairing whichever two leave the smallest result — the rule the libraries ship — is optimal on 50.0 per cent with a median of 1.0026. The upper curve is the spread between each network's own best and worst orders, median 607, which is the size of the thing being searched for.

heuristic-excess is one function in lib/figures/contract.js — contraction order — one expression, one value, and orders that differ by two million. Everything below came out of it during this build, at arguments taken from the essays rather than invented for this page. A figure here is the figure a reader meets in an essay, and if the generator changes, this page changes with it.

Each curve is one rule's excess over the exhaustive answer, sorted, so the horizontal axis is the share of networks at or below that excess. Pairing whichever two operands are cheapest to multiply is optimal on 1.7 per cent of them, has a median excess of 1.446 and a worst case of 25.4. Pairing whichever two leave the smallest result — the rule the libraries ship — is optimal on 50.0 per cent with a median of 1.0026. The upper curve is the spread between each network's own best and worst orders, median 607, which is the size of the thing being searched for.

Each curve is one rule's excess over the exhaustive answer, sorted, so the horizontal axis is the share of networks at or below that excess. Pairing whichever two operands are cheapest to multiply is optimal on 1.7 per cent of them, has a median excess of 1.446 and a worst case of 25.4. Pairing whichever two leave the smallest result — the rule the libraries ship — is optimal on 50.0 per cent with a median of 1.0026. The upper curve is the spread between each network's own best and worst orders, median 607, which is the size of the thing being searched for.

Each curve is one rule's excess over the exhaustive answer, sorted, so the horizontal axis is the share of networks at or below that excess. Pairing whichever two operands are cheapest to multiply is optimal on 3.3 per cent of them, has a median excess of 1.471 and a worst case of 25.4. Pairing whichever two leave the smallest result — the rule the libraries ship — is optimal on 53.3 per cent with a median of 1.0000. The upper curve is the spread between each network's own best and worst orders, median 558.9, which is the size of the thing being searched for.

Each curve is one rule's excess over the exhaustive answer, sorted, so the horizontal axis is the share of networks at or below that excess. Pairing whichever two operands are cheapest to multiply is optimal on 0.0 per cent of them, has a median excess of 1.337 and a worst case of 25.4. Pairing whichever two leave the smallest result — the rule the libraries ship — is optimal on 42.5 per cent with a median of 1.0140. The upper curve is the spread between each network's own best and worst orders, median 639.8, which is the size of the thing being searched for.

Each curve is one rule's excess over the exhaustive answer, sorted, so the horizontal axis is the share of networks at or below that excess. Pairing whichever two operands are cheapest to multiply is optimal on 0.0 per cent of them, has a median excess of 1.296 and a worst case of 7.53. Pairing whichever two leave the smallest result — the rule the libraries ship — is optimal on 50.0 per cent with a median of 1.0034. The upper curve is the spread between each network's own best and worst orders, median 810.1, which is the size of the thing being searched for.

Each curve is one rule's excess over the exhaustive answer, sorted, so the horizontal axis is the share of networks at or below that excess. Pairing whichever two operands are cheapest to multiply is optimal on 1.1 per cent of them, has a median excess of 1.443 and a worst case of 25.4. Pairing whichever two leave the smallest result — the rule the libraries ship — is optimal on 50.0 per cent with a median of 1.0026. The upper curve is the spread between each network's own best and worst orders, median 538.6, which is the size of the thing being searched for.

Every figure above asserted its own claims on the way to being drawn, and a claim that failed would have failed the build rather than drawn a wrong picture. Those assertions used to leave no trace at all: a passing one returned true and the only evidence the figure had checked anything was that nothing crashed. The list below is what they actually said, collected by running this generator with an observer installed — not a description of what it is believed to check.

3 distinct claims across 6 sets of arguments, grouped below by shape — because most of them are one sentence with a different number in it, and how many separate times that sentence was put to the test is the informative part.

The rule does not apply to it. It factorises nothing, so there is no residual it could be withholding. That is worth stating rather than leaving blank: a site that reported the rule as satisfied by every generator would be counting mostly generators the rule never reached.

Across the library: the rule bites on 146 of 287 generators — 131 print a residual and 15 are exempt with a published reason; 141 factorise nothing. Read from lib/residual-rule.js, which is the same body the gate enforces from, and the gate's last check fails the build if this page and it disagree about any generator.