Как метод Monte Carlo применяется для прогнозирования тенниса через модель Glicko-2. Точная симуляция от очка до матча.
Monte Carlo — общий вычислительный метод, использующий случайную выборку для решения задач, аналитически трудноразрешимых. В контексте тенниса: если мы знаем вероятность игрока A выиграть одно очко на подаче (допустим 65%), мы можем численно смоделировать полный матч 3000 раз, подбрасывая виртуальные «монеты» с этой вероятностью на каждое очко. Результаты 3000 симуляций дают эмпирическое распределение исходов — из него мы считаем P(match wins), P(margin ≥ 3.5 games), P(total > 22.5) и любые другие marginals.
Формулы есть для простых исходов (P(match wins) → closed-form через матрицу состояний сета). Но для complex исходов (распределение margin, total) аналитика требует интегрирования по множеству состояний — это очень медленно или impossible без упрощений. MC: (1) Естественно даёт полное распределение, не только среднее. (2) Легко добавлять детали (tiebreak physics, let courts, injuries mid-match). (3) Параллелизируется — 3000 сим за 50-80ms на CPU. (4) Не нужно обучение на данных — только параметры игрока (Glicko-2 rating) + правила тенниса.
Шаг 1 — Glicko-2 → P(point on serve). Для каждого игрока: P(выигрыш очка на своей подаче) = σ(k × (serve_rating_A − return_rating_B)), где σ — logistic, k — калибровочная константа. В StarkTennis k = 1/250. Шаг 2 — P(point) → P(hold game). Аналитическая формула для выигрыша gam'а (нужно 4 очка с преимуществом 2). Шаг 3 — P(hold) обоих → P(win set). Рекурсивная матрица состояний 6:0, 6:1, 6:2, 6:3, 6:4, 7:5, 7:6. Шаг 4 — Monte Carlo всего матча: подбрасываем коины для каждого гема, пока либо 2:0, 2:1 (BO3) либо 3:0, 3:1, 3:2 (BO5). Фиксируем total games (для Total) и margin (для HC).
В pure_math.py функция `margin_distribution(pa_hold, pb_hold, bo, n=3000)`: (1) runs 3000 independent matches through `simulate_match()`. (2) Записывает `(games_a, games_b)` каждой симуляции. (3) Эмпирически считает P(A covers −line) для всех standard lines (−2.5, −3.5, −4.5, −5.5). (4) Возвращает dict с P для каждой линии + mean/std margin + mean total. Кэшируется по (pa_hold, pb_hold, bo) — одна MC run обслуживает все HC + Total линии для матча. Latency ~50-80ms на матч. Для batch 16 матчей (типичный export) — ~1 секунда.
Стандартная ошибка MC оценки зависит от n и p: SE(P) = √(p × (1 − p) / n). Для n=3000 и p=0.5 (наихудший случай) — SE = 0.91%. Для наших порогов edge ≥8%, это достаточно. Увеличение до n=10000 даёт SE = 0.5%, но 3x медленнее. Выбран sweet spot 3000. В критических edge cases (value точно на границе 8%) рекомендуется проверить с n=10000 для confidence.
Ключевое преимущество MC подхода — model не переобучается на исторические данные. ML модели (XGBoost, CatBoost, LineMove) обучены на истории, имеют biases которые могут overfit common patterns. Pure Math использует only Glicko-2 ratings (они обновляются incrementally) и правила тенниса (детерминистские). Её ошибки — только от неточности Glicko-2 ratings, а не от pattern matching. Это делает Pure Math статистически НЕЗАВИСИМЫМ от ML прогнозов. Ансамбль из Pure Math + ML variants даёт лучший calibration (variance снижается), что и использует Trio meta-consensus (нужны 3+ независимых голоса).
Баланс между точностью и скоростью. SE ~0.9% при 3000 vs 1.6% при 1000 vs 0.5% при 10000. Для наших edge thresholds 3000 достаточно без overhead.
Да. Параметр `bo=5` в `simulate_match`. Логика matrices расширяется до 3 наборных побед. Тоталы на BO5 медиана 30-32 vs 20-22 на BO3.
Технически да — через динамическое изменение P(point) в течение матча. Но это потребует более сложной модели (momentum is controversial в sports analytics). В первой версии StarkTennis MC — simple iid points. Это нормально для pre-match. Live модели — отдельный research.
Теория — полезно, практика — полезнее. Все модели StarkTennis работают в реальном времени:
📊 Открыть миниаппTelegram канал: @cxcap. Обновление каждые 30 минут. Всё бесплатно.