edgepoint 3.0.2__tar.gz → 3.5.1__tar.gz

{edgepoint-3.0.2 → edgepoint-3.5.1}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: edgepoint
-Version: 3.0.2
+Version: 3.5.1
 Summary: Find the point in a numeric column above which a binary outcome becomes meaningfully and reliably better.
 Author: Henry
 License: MIT
@@ -109,32 +109,31 @@ from edgepoint import search
 
 df = pd.DataFrame({
     "score": [
-        72.68, 58.92, 62.15, 8.13, 33.3, 66.19, 73.79, 35.43,
-        65.06, 63.13, 61.47, 45.13, 39.16, 38.15, 29.41, 59.91,
-        54.12, 86.35, 76.02, 63.13, 51.63, 0, 77.4, 81.66,
-        50.13, 52.4, 52.82, 86.12, 57.58, 13.66, 37.29, 32.91,
-        73.66, 96.2, 36.3, 22.74, 65.54, 23.98, 61.59, 32.27
+        63.94, 22.32, 89.22, 2.98, 2.65, 54.49, 80.94, 69.81,
+        95.72, 9.67, 80.71, 97.31, 82.94, 57.74, 22.79, 23.28,
+        63.57, 20.95, 64.80, 72.91, 98.95, 68.46, 22.90, 26.77,
+        87.64, 39.56, 26.49, 26.27, 39.94, 50.95, 10.96, 42.22,
+        99.61, 86.08, 68.17, 64.10, 45.37, 26.34, 91.26, 63.89
     ],
     "age": [
-        33.9, 41.9, 30.8, 56.5, 45.8, 45.1, 43.3, 54.3,
-        52.5, 54.2, 43.9, 18, 31.3, 38, 48.3, 55.8,
-        35.4, 56, 20.2, 27.7, 28.1, 39.4, 44.3, 39.9,
-        53.6, 26.1, 63.1, 42.3, 46.3, 20.2, 39.2, 35.3,
-        27.7, 31.8, 26.5, 32.2, 35.1, 43.5, 45.8, 43.8
+        19.2, 52.6, 22.1, 28.3, 27.3, 28.4, 18.3, 34.0,
+        33.8, 57.8, 52.3, 35.8, 47.1, 51.1, 31.6, 22.7,
+        35.1, 30.5, 46.6, 25.7, 48.1, 57.6, 19.5, 27.9,
+        32.8, 61.0, 29.6, 45.5, 28.3, 22.3, 47.5, 21.0,
+        42.9, 18.5, 43.2, 23.2, 62.8, 41.5, 58.9, 46.6
     ],
     "hit": [
-        1, 1, 0, 0, 0, 1, 1, 0,
-        0, 1, 1, 0, 0, 0, 0, 1,
-        1, 1, 1, 1, 0, 0, 0, 1,
-        0, 1, 1, 1, 0, 0, 0, 0,
-        1, 1, 0, 0, 1, 0, 1, 0
+        1, 0, 0, 0, 0, 0, 0, 1,
+        1, 0, 1, 0, 0, 1, 1, 0,
+        1, 0, 1, 1, 1, 1, 0, 0,
+        0, 0, 0, 0, 0, 1, 0, 0,
+        0, 0, 1, 0, 0, 1, 1, 1
     ]
 })
 
 edgepoints_df, top_combos = search(
     df,
     outcome_col="hit",
-    mode="quick",
     min_coverage=10,
     show_progress=True,
     top_combo_n=3,
@@ -180,9 +179,10 @@ for you from the data itself:
    ratio to configure.
 2. **Train section**: every numeric column is searched for its best
    single-column threshold (percentile-based candidate edges, scored on
-   a shrinkage-discounted gap/coverage blend), then qualifying columns
-   are combined into AND-combinations (size capped by `mode`) and
-   k-fold validated on train itself.
+   a shrinkage-discounted gap/coverage blend). Columns that clear the
+   baseline are then combined into AND-combinations, capped at a combo
+   size **worked out automatically** (see below), and k-fold validated
+   on train itself.
 3. **Test section**: every train-side edge and surviving combo is
    replayed against test, unchanged, with its own k-fold validation.
 4. **Merge edges**: train and test side stats for each column are
@@ -200,19 +200,30 @@ stage. Nothing is ever re-tuned on test.
 
 ---
 
-## Modes
-
-`mode` controls how large a column combination can get during combo
-search:
-
-| Mode         | Combo size                                                          |
-| ------------ | -------------------------------------------------------------------- |
-| `"quick"`    | up to 2 columns per combo                                            |
-| `"standard"` | up to 3 columns per combo                                             |
-| `"deep"`     | auto-fit, the largest size that keeps total combos under a fixed safety ceiling |
-
-`"quick"`/`"standard"` are refused up front if they'd blow past that
-ceiling given how many columns qualified.
+## Automatic combo-size capping (no `mode` to set)
+
+Earlier versions asked you to pick a `mode` (`"quick"` / `"standard"` /
+`"deep"`) to control how large a column combination could get. That's
+gone. **The cap is now worked out automatically for every run**, from
+two independent limits, and the smaller one always wins:
+
+- **Row cap**: how big a combo can you actually *trust* given how much
+  data you have? ANDing four conditions together on 76 rows slices the
+  data down to almost nothing per combo, that's a straight overfitting
+  risk, not a compute one. This cap comes purely from row count.
+- **Memory cap**: how big a combo can the machine *afford* to generate
+  before the number of combinations blows past a fixed safety ceiling?
+  This cap comes purely from column count, nothing statistical about it.
+
+`search()` always uses `min(row_cap, memory_cap)`, so a combo size is
+never allowed past whichever limit is more restrictive. This removes a
+real footgun: a `mode="deep"` setting on a small dataset used to let
+combo size grow well past what the row count could statistically
+support, manufacturing an impressive-looking combo that was really just
+overfitting a handful of rows. Now that ceiling is enforced automatically
+on every run, there's no setting to accidentally crank up and no need to
+know how many rows is "enough" for a given combo size, `search()` works
+it out for you and never lets you shoot yourself in the foot.
 
 ---
 
@@ -222,7 +233,6 @@ ceiling given how many columns qualified.
 | -------------- | ------- | ----------------------------------------------------------------------------- |
 | `df`           | required | Input DataFrame                                                              |
 | `outcome_col`  | `"hit"` | Binary outcome column (`0`/`1`, `True`/`False`, or a mix)                     |
-| `mode`         | `"quick"` | `"quick"`, `"standard"`, or `"deep"`, controls combo size, see above       |
 | `min_coverage` | `10`    | Minimum % of rows a threshold/combo must cover to qualify (train and test)   |
 | `show_progress`| `True`  | Print the full stage-by-stage log                                            |
 | `top_combo_n`  | `3`     | How many top combos to return. `1` returns a single dict; more returns a list |
@@ -242,14 +252,16 @@ with train (`_tr`) and test (`_te`) versions of `hit_rate`, `miss_rate`,
 
 ```python
 {
-    "combo_num": 3,
+    "combo_num": 2,
     "combo": "score, age",
-    "edges": {"score": 49.46, "age": 39.5},
-    "hit_rate_tr": 80.0, "hit_rate_te": 60.0,
-    "coverage_tr": 41.67, "coverage_te": 31.25,
-    "n_tr": 10, "n_te": 5,
-    "score_tr": 0.62, "score_te": 0.41,
-    "final_score": 21.49,
+    "edges": {"score": 55.0, "age": 40.0},
+    "hit_rate_tr": 83.33, "hit_rate_te": 75.0,
+    "coverage_tr": 20.0, "coverage_te": 40.0,
+    "n_tr": 6, "n_te": 4,
+    "score_tr": 0.71, "score_te": 0.55,
+    "final_score": 64.6,
+    "baseline_full": 40.0,
+    "vs_baseline": 35.0,
 }
 ```
 
@@ -260,17 +272,19 @@ empty `edges`.
 
 Think of `top_combos` as the answer to *"which traits, combined,
 actually separate my winners from everyone else, and by how much?"*
-A single-column result might tell you customers 34+ buy at 58% vs 22%
-for everyone else, useful, but crude, since plenty of 22-year-olds buy
-too. A combo sharpens that: `age >= 34 AND minutes_on_site >= 6.5` might
-come back at a 71% hit rate on train and 68% on test, covering 18% of
-visitors against a 24% baseline. That's a different, more useful claim.
-It's not age alone, it's that age *stacked with* engagement time is
-where the real signal was hiding, and it held up on data the search
-never saw. `top_combos` typically hands you a few of these to compare,
-so you can weigh, say, "age + time on site" against "past purchases +
-email opens," and pick whichever combo is both strong *and* backed by
-enough rows (`n_tr`/`n_te`) to actually trust.
+A single-column result might tell you `score >= 55` alone gets you a
+66.67% hit rate on train (covering half the rows) and `age >= 40` alone
+only gets you 50%, useful, but each is still riding along with a lot of
+noise. A combo sharpens that: `score >= 55.0 AND age >= 40.0` comes back
+at an 83.33% hit rate on train and 75.0% on test, covering a thinner but
+much sharper 20-40% of rows, against a 40% baseline. That's the real
+claim, it's not score alone or age alone, it's that the two *stacked
+together* is where the actual separation was hiding, and it held up on
+data the search never saw (`vs_baseline: 35.0` means even the weaker of
+the two splits still beat "doing nothing" by 35 points). `top_combos`
+typically hands you a few of these to compare, so you can weigh one
+combo's strength against another's, and pick whichever is both strong
+*and* backed by enough rows (`n_tr`/`n_te`) to actually trust.
 
 ---
 
@@ -308,6 +322,10 @@ per-column skip.
 - **Sign-flip penalty**: if a combo's gap direction flips between train
   and test, that's a concrete overfitting signal, so `final_score` is
   halved for that row.
+- **Automatic combo-size capping**: combo size is capped by the
+  stricter of a row-count-based statistical limit and a memory-based
+  safety ceiling, see "Automatic combo-size capping" above, there's no
+  `mode` to set and no way to override this cap.
 - **One-directional search**: `edgepoint` only asks "is there a point
   above which the rate is *better*?" It doesn't independently verify the
   below side against its own bar.

{edgepoint-3.0.2 → edgepoint-3.5.1}/README.md

@@ -81,32 +81,31 @@ from edgepoint import search
 
 df = pd.DataFrame({
     "score": [
-        72.68, 58.92, 62.15, 8.13, 33.3, 66.19, 73.79, 35.43,
-        65.06, 63.13, 61.47, 45.13, 39.16, 38.15, 29.41, 59.91,
-        54.12, 86.35, 76.02, 63.13, 51.63, 0, 77.4, 81.66,
-        50.13, 52.4, 52.82, 86.12, 57.58, 13.66, 37.29, 32.91,
-        73.66, 96.2, 36.3, 22.74, 65.54, 23.98, 61.59, 32.27
+        63.94, 22.32, 89.22, 2.98, 2.65, 54.49, 80.94, 69.81,
+        95.72, 9.67, 80.71, 97.31, 82.94, 57.74, 22.79, 23.28,
+        63.57, 20.95, 64.80, 72.91, 98.95, 68.46, 22.90, 26.77,
+        87.64, 39.56, 26.49, 26.27, 39.94, 50.95, 10.96, 42.22,
+        99.61, 86.08, 68.17, 64.10, 45.37, 26.34, 91.26, 63.89
     ],
     "age": [
-        33.9, 41.9, 30.8, 56.5, 45.8, 45.1, 43.3, 54.3,
-        52.5, 54.2, 43.9, 18, 31.3, 38, 48.3, 55.8,
-        35.4, 56, 20.2, 27.7, 28.1, 39.4, 44.3, 39.9,
-        53.6, 26.1, 63.1, 42.3, 46.3, 20.2, 39.2, 35.3,
-        27.7, 31.8, 26.5, 32.2, 35.1, 43.5, 45.8, 43.8
+        19.2, 52.6, 22.1, 28.3, 27.3, 28.4, 18.3, 34.0,
+        33.8, 57.8, 52.3, 35.8, 47.1, 51.1, 31.6, 22.7,
+        35.1, 30.5, 46.6, 25.7, 48.1, 57.6, 19.5, 27.9,
+        32.8, 61.0, 29.6, 45.5, 28.3, 22.3, 47.5, 21.0,
+        42.9, 18.5, 43.2, 23.2, 62.8, 41.5, 58.9, 46.6
     ],
     "hit": [
-        1, 1, 0, 0, 0, 1, 1, 0,
-        0, 1, 1, 0, 0, 0, 0, 1,
-        1, 1, 1, 1, 0, 0, 0, 1,
-        0, 1, 1, 1, 0, 0, 0, 0,
-        1, 1, 0, 0, 1, 0, 1, 0
+        1, 0, 0, 0, 0, 0, 0, 1,
+        1, 0, 1, 0, 0, 1, 1, 0,
+        1, 0, 1, 1, 1, 1, 0, 0,
+        0, 0, 0, 0, 0, 1, 0, 0,
+        0, 0, 1, 0, 0, 1, 1, 1
     ]
 })
 
 edgepoints_df, top_combos = search(
     df,
     outcome_col="hit",
-    mode="quick",
     min_coverage=10,
     show_progress=True,
     top_combo_n=3,
@@ -152,9 +151,10 @@ for you from the data itself:
    ratio to configure.
 2. **Train section**: every numeric column is searched for its best
    single-column threshold (percentile-based candidate edges, scored on
-   a shrinkage-discounted gap/coverage blend), then qualifying columns
-   are combined into AND-combinations (size capped by `mode`) and
-   k-fold validated on train itself.
+   a shrinkage-discounted gap/coverage blend). Columns that clear the
+   baseline are then combined into AND-combinations, capped at a combo
+   size **worked out automatically** (see below), and k-fold validated
+   on train itself.
 3. **Test section**: every train-side edge and surviving combo is
    replayed against test, unchanged, with its own k-fold validation.
 4. **Merge edges**: train and test side stats for each column are
@@ -172,19 +172,30 @@ stage. Nothing is ever re-tuned on test.
 
 ---
 
-## Modes
-
-`mode` controls how large a column combination can get during combo
-search:
-
-| Mode         | Combo size                                                          |
-| ------------ | -------------------------------------------------------------------- |
-| `"quick"`    | up to 2 columns per combo                                            |
-| `"standard"` | up to 3 columns per combo                                             |
-| `"deep"`     | auto-fit, the largest size that keeps total combos under a fixed safety ceiling |
-
-`"quick"`/`"standard"` are refused up front if they'd blow past that
-ceiling given how many columns qualified.
+## Automatic combo-size capping (no `mode` to set)
+
+Earlier versions asked you to pick a `mode` (`"quick"` / `"standard"` /
+`"deep"`) to control how large a column combination could get. That's
+gone. **The cap is now worked out automatically for every run**, from
+two independent limits, and the smaller one always wins:
+
+- **Row cap**: how big a combo can you actually *trust* given how much
+  data you have? ANDing four conditions together on 76 rows slices the
+  data down to almost nothing per combo, that's a straight overfitting
+  risk, not a compute one. This cap comes purely from row count.
+- **Memory cap**: how big a combo can the machine *afford* to generate
+  before the number of combinations blows past a fixed safety ceiling?
+  This cap comes purely from column count, nothing statistical about it.
+
+`search()` always uses `min(row_cap, memory_cap)`, so a combo size is
+never allowed past whichever limit is more restrictive. This removes a
+real footgun: a `mode="deep"` setting on a small dataset used to let
+combo size grow well past what the row count could statistically
+support, manufacturing an impressive-looking combo that was really just
+overfitting a handful of rows. Now that ceiling is enforced automatically
+on every run, there's no setting to accidentally crank up and no need to
+know how many rows is "enough" for a given combo size, `search()` works
+it out for you and never lets you shoot yourself in the foot.
 
 ---
 
@@ -194,7 +205,6 @@ ceiling given how many columns qualified.
 | -------------- | ------- | ----------------------------------------------------------------------------- |
 | `df`           | required | Input DataFrame                                                              |
 | `outcome_col`  | `"hit"` | Binary outcome column (`0`/`1`, `True`/`False`, or a mix)                     |
-| `mode`         | `"quick"` | `"quick"`, `"standard"`, or `"deep"`, controls combo size, see above       |
 | `min_coverage` | `10`    | Minimum % of rows a threshold/combo must cover to qualify (train and test)   |
 | `show_progress`| `True`  | Print the full stage-by-stage log                                            |
 | `top_combo_n`  | `3`     | How many top combos to return. `1` returns a single dict; more returns a list |
@@ -214,14 +224,16 @@ with train (`_tr`) and test (`_te`) versions of `hit_rate`, `miss_rate`,
 
 ```python
 {
-    "combo_num": 3,
+    "combo_num": 2,
     "combo": "score, age",
-    "edges": {"score": 49.46, "age": 39.5},
-    "hit_rate_tr": 80.0, "hit_rate_te": 60.0,
-    "coverage_tr": 41.67, "coverage_te": 31.25,
-    "n_tr": 10, "n_te": 5,
-    "score_tr": 0.62, "score_te": 0.41,
-    "final_score": 21.49,
+    "edges": {"score": 55.0, "age": 40.0},
+    "hit_rate_tr": 83.33, "hit_rate_te": 75.0,
+    "coverage_tr": 20.0, "coverage_te": 40.0,
+    "n_tr": 6, "n_te": 4,
+    "score_tr": 0.71, "score_te": 0.55,
+    "final_score": 64.6,
+    "baseline_full": 40.0,
+    "vs_baseline": 35.0,
 }
 ```
 
@@ -232,17 +244,19 @@ empty `edges`.
 
 Think of `top_combos` as the answer to *"which traits, combined,
 actually separate my winners from everyone else, and by how much?"*
-A single-column result might tell you customers 34+ buy at 58% vs 22%
-for everyone else, useful, but crude, since plenty of 22-year-olds buy
-too. A combo sharpens that: `age >= 34 AND minutes_on_site >= 6.5` might
-come back at a 71% hit rate on train and 68% on test, covering 18% of
-visitors against a 24% baseline. That's a different, more useful claim.
-It's not age alone, it's that age *stacked with* engagement time is
-where the real signal was hiding, and it held up on data the search
-never saw. `top_combos` typically hands you a few of these to compare,
-so you can weigh, say, "age + time on site" against "past purchases +
-email opens," and pick whichever combo is both strong *and* backed by
-enough rows (`n_tr`/`n_te`) to actually trust.
+A single-column result might tell you `score >= 55` alone gets you a
+66.67% hit rate on train (covering half the rows) and `age >= 40` alone
+only gets you 50%, useful, but each is still riding along with a lot of
+noise. A combo sharpens that: `score >= 55.0 AND age >= 40.0` comes back
+at an 83.33% hit rate on train and 75.0% on test, covering a thinner but
+much sharper 20-40% of rows, against a 40% baseline. That's the real
+claim, it's not score alone or age alone, it's that the two *stacked
+together* is where the actual separation was hiding, and it held up on
+data the search never saw (`vs_baseline: 35.0` means even the weaker of
+the two splits still beat "doing nothing" by 35 points). `top_combos`
+typically hands you a few of these to compare, so you can weigh one
+combo's strength against another's, and pick whichever is both strong
+*and* backed by enough rows (`n_tr`/`n_te`) to actually trust.
 
 ---
 
@@ -280,6 +294,10 @@ per-column skip.
 - **Sign-flip penalty**: if a combo's gap direction flips between train
   and test, that's a concrete overfitting signal, so `final_score` is
   halved for that row.
+- **Automatic combo-size capping**: combo size is capped by the
+  stricter of a row-count-based statistical limit and a memory-based
+  safety ceiling, see "Automatic combo-size capping" above, there's no
+  `mode` to set and no way to override this cap.
 - **One-directional search**: `edgepoint` only asks "is there a point
   above which the rate is *better*?" It doesn't independently verify the
   below side against its own bar.

{edgepoint-3.0.2 → edgepoint-3.5.1}/edgepoint.egg-info/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: edgepoint
-Version: 3.0.2
+Version: 3.5.1
 Summary: Find the point in a numeric column above which a binary outcome becomes meaningfully and reliably better.
 Author: Henry
 License: MIT
@@ -109,32 +109,31 @@ from edgepoint import search
 
 df = pd.DataFrame({
     "score": [
-        72.68, 58.92, 62.15, 8.13, 33.3, 66.19, 73.79, 35.43,
-        65.06, 63.13, 61.47, 45.13, 39.16, 38.15, 29.41, 59.91,
-        54.12, 86.35, 76.02, 63.13, 51.63, 0, 77.4, 81.66,
-        50.13, 52.4, 52.82, 86.12, 57.58, 13.66, 37.29, 32.91,
-        73.66, 96.2, 36.3, 22.74, 65.54, 23.98, 61.59, 32.27
+        63.94, 22.32, 89.22, 2.98, 2.65, 54.49, 80.94, 69.81,
+        95.72, 9.67, 80.71, 97.31, 82.94, 57.74, 22.79, 23.28,
+        63.57, 20.95, 64.80, 72.91, 98.95, 68.46, 22.90, 26.77,
+        87.64, 39.56, 26.49, 26.27, 39.94, 50.95, 10.96, 42.22,
+        99.61, 86.08, 68.17, 64.10, 45.37, 26.34, 91.26, 63.89
     ],
     "age": [
-        33.9, 41.9, 30.8, 56.5, 45.8, 45.1, 43.3, 54.3,
-        52.5, 54.2, 43.9, 18, 31.3, 38, 48.3, 55.8,
-        35.4, 56, 20.2, 27.7, 28.1, 39.4, 44.3, 39.9,
-        53.6, 26.1, 63.1, 42.3, 46.3, 20.2, 39.2, 35.3,
-        27.7, 31.8, 26.5, 32.2, 35.1, 43.5, 45.8, 43.8
+        19.2, 52.6, 22.1, 28.3, 27.3, 28.4, 18.3, 34.0,
+        33.8, 57.8, 52.3, 35.8, 47.1, 51.1, 31.6, 22.7,
+        35.1, 30.5, 46.6, 25.7, 48.1, 57.6, 19.5, 27.9,
+        32.8, 61.0, 29.6, 45.5, 28.3, 22.3, 47.5, 21.0,
+        42.9, 18.5, 43.2, 23.2, 62.8, 41.5, 58.9, 46.6
     ],
     "hit": [
-        1, 1, 0, 0, 0, 1, 1, 0,
-        0, 1, 1, 0, 0, 0, 0, 1,
-        1, 1, 1, 1, 0, 0, 0, 1,
-        0, 1, 1, 1, 0, 0, 0, 0,
-        1, 1, 0, 0, 1, 0, 1, 0
+        1, 0, 0, 0, 0, 0, 0, 1,
+        1, 0, 1, 0, 0, 1, 1, 0,
+        1, 0, 1, 1, 1, 1, 0, 0,
+        0, 0, 0, 0, 0, 1, 0, 0,
+        0, 0, 1, 0, 0, 1, 1, 1
     ]
 })
 
 edgepoints_df, top_combos = search(
     df,
     outcome_col="hit",
-    mode="quick",
     min_coverage=10,
     show_progress=True,
     top_combo_n=3,
@@ -180,9 +179,10 @@ for you from the data itself:
    ratio to configure.
 2. **Train section**: every numeric column is searched for its best
    single-column threshold (percentile-based candidate edges, scored on
-   a shrinkage-discounted gap/coverage blend), then qualifying columns
-   are combined into AND-combinations (size capped by `mode`) and
-   k-fold validated on train itself.
+   a shrinkage-discounted gap/coverage blend). Columns that clear the
+   baseline are then combined into AND-combinations, capped at a combo
+   size **worked out automatically** (see below), and k-fold validated
+   on train itself.
 3. **Test section**: every train-side edge and surviving combo is
    replayed against test, unchanged, with its own k-fold validation.
 4. **Merge edges**: train and test side stats for each column are
@@ -200,19 +200,30 @@ stage. Nothing is ever re-tuned on test.
 
 ---
 
-## Modes
-
-`mode` controls how large a column combination can get during combo
-search:
-
-| Mode         | Combo size                                                          |
-| ------------ | -------------------------------------------------------------------- |
-| `"quick"`    | up to 2 columns per combo                                            |
-| `"standard"` | up to 3 columns per combo                                             |
-| `"deep"`     | auto-fit, the largest size that keeps total combos under a fixed safety ceiling |
-
-`"quick"`/`"standard"` are refused up front if they'd blow past that
-ceiling given how many columns qualified.
+## Automatic combo-size capping (no `mode` to set)
+
+Earlier versions asked you to pick a `mode` (`"quick"` / `"standard"` /
+`"deep"`) to control how large a column combination could get. That's
+gone. **The cap is now worked out automatically for every run**, from
+two independent limits, and the smaller one always wins:
+
+- **Row cap**: how big a combo can you actually *trust* given how much
+  data you have? ANDing four conditions together on 76 rows slices the
+  data down to almost nothing per combo, that's a straight overfitting
+  risk, not a compute one. This cap comes purely from row count.
+- **Memory cap**: how big a combo can the machine *afford* to generate
+  before the number of combinations blows past a fixed safety ceiling?
+  This cap comes purely from column count, nothing statistical about it.
+
+`search()` always uses `min(row_cap, memory_cap)`, so a combo size is
+never allowed past whichever limit is more restrictive. This removes a
+real footgun: a `mode="deep"` setting on a small dataset used to let
+combo size grow well past what the row count could statistically
+support, manufacturing an impressive-looking combo that was really just
+overfitting a handful of rows. Now that ceiling is enforced automatically
+on every run, there's no setting to accidentally crank up and no need to
+know how many rows is "enough" for a given combo size, `search()` works
+it out for you and never lets you shoot yourself in the foot.
 
 ---
 
@@ -222,7 +233,6 @@ ceiling given how many columns qualified.
 | -------------- | ------- | ----------------------------------------------------------------------------- |
 | `df`           | required | Input DataFrame                                                              |
 | `outcome_col`  | `"hit"` | Binary outcome column (`0`/`1`, `True`/`False`, or a mix)                     |
-| `mode`         | `"quick"` | `"quick"`, `"standard"`, or `"deep"`, controls combo size, see above       |
 | `min_coverage` | `10`    | Minimum % of rows a threshold/combo must cover to qualify (train and test)   |
 | `show_progress`| `True`  | Print the full stage-by-stage log                                            |
 | `top_combo_n`  | `3`     | How many top combos to return. `1` returns a single dict; more returns a list |
@@ -242,14 +252,16 @@ with train (`_tr`) and test (`_te`) versions of `hit_rate`, `miss_rate`,
 
 ```python
 {
-    "combo_num": 3,
+    "combo_num": 2,
     "combo": "score, age",
-    "edges": {"score": 49.46, "age": 39.5},
-    "hit_rate_tr": 80.0, "hit_rate_te": 60.0,
-    "coverage_tr": 41.67, "coverage_te": 31.25,
-    "n_tr": 10, "n_te": 5,
-    "score_tr": 0.62, "score_te": 0.41,
-    "final_score": 21.49,
+    "edges": {"score": 55.0, "age": 40.0},
+    "hit_rate_tr": 83.33, "hit_rate_te": 75.0,
+    "coverage_tr": 20.0, "coverage_te": 40.0,
+    "n_tr": 6, "n_te": 4,
+    "score_tr": 0.71, "score_te": 0.55,
+    "final_score": 64.6,
+    "baseline_full": 40.0,
+    "vs_baseline": 35.0,
 }
 ```
 
@@ -260,17 +272,19 @@ empty `edges`.
 
 Think of `top_combos` as the answer to *"which traits, combined,
 actually separate my winners from everyone else, and by how much?"*
-A single-column result might tell you customers 34+ buy at 58% vs 22%
-for everyone else, useful, but crude, since plenty of 22-year-olds buy
-too. A combo sharpens that: `age >= 34 AND minutes_on_site >= 6.5` might
-come back at a 71% hit rate on train and 68% on test, covering 18% of
-visitors against a 24% baseline. That's a different, more useful claim.
-It's not age alone, it's that age *stacked with* engagement time is
-where the real signal was hiding, and it held up on data the search
-never saw. `top_combos` typically hands you a few of these to compare,
-so you can weigh, say, "age + time on site" against "past purchases +
-email opens," and pick whichever combo is both strong *and* backed by
-enough rows (`n_tr`/`n_te`) to actually trust.
+A single-column result might tell you `score >= 55` alone gets you a
+66.67% hit rate on train (covering half the rows) and `age >= 40` alone
+only gets you 50%, useful, but each is still riding along with a lot of
+noise. A combo sharpens that: `score >= 55.0 AND age >= 40.0` comes back
+at an 83.33% hit rate on train and 75.0% on test, covering a thinner but
+much sharper 20-40% of rows, against a 40% baseline. That's the real
+claim, it's not score alone or age alone, it's that the two *stacked
+together* is where the actual separation was hiding, and it held up on
+data the search never saw (`vs_baseline: 35.0` means even the weaker of
+the two splits still beat "doing nothing" by 35 points). `top_combos`
+typically hands you a few of these to compare, so you can weigh one
+combo's strength against another's, and pick whichever is both strong
+*and* backed by enough rows (`n_tr`/`n_te`) to actually trust.
 
 ---
 
@@ -308,6 +322,10 @@ per-column skip.
 - **Sign-flip penalty**: if a combo's gap direction flips between train
   and test, that's a concrete overfitting signal, so `final_score` is
   halved for that row.
+- **Automatic combo-size capping**: combo size is capped by the
+  stricter of a row-count-based statistical limit and a memory-based
+  safety ceiling, see "Automatic combo-size capping" above, there's no
+  `mode` to set and no way to override this cap.
 - **One-directional search**: `edgepoint` only asks "is there a point
   above which the rate is *better*?" It doesn't independently verify the
   below side against its own bar.

{edgepoint-3.0.2 → edgepoint-3.5.1}/edgepoint.egg-info/SOURCES.txt

@@ -6,9 +6,7 @@ edgepoint/__init__.py
 edgepoint/aggregate_kfold_combos.py
 edgepoint/aggregate_kfold_edges.py
 edgepoint/core.py
-edgepoint/core_v1.py
 edgepoint/main.py
-edgepoint/main_old.py
 edgepoint/run_kfold_find.py
 edgepoint/run_kfold_search.py
 edgepoint/sanity_check.py

{edgepoint-3.0.2 → edgepoint-3.5.1}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "setuptools.build_meta"
 
 [project]
 name = "edgepoint"
-version = "3.0.2"
+version = "3.5.1"
 description = "Find the point in a numeric column above which a binary outcome becomes meaningfully and reliably better."
 readme = "README.md"
 requires-python = ">=3.9"

{edgepoint-3.0.2 → edgepoint-3.5.1}/setup.py

@@ -5,7 +5,7 @@ long_description = (Path(__file__).parent / "README.md").read_text(encoding="utf
 
 setup(
     name="edgepoint",
-    version="3.0.2",
+    version="3.5.1",
     author="Henry",
     description="Find where a metric, or combination of metrics, starts getting better while keeping the best coverage possible, then check if that holds on unseen data.",
     long_description=long_description,