Півоти кількох таймфреймів: підтвердження й доступність даних

Практична послідовність дій

1. Розраховуйте окремоКожен таймфрейм має власні бари, півоти й календар.
2. Запишіть час доступностіВрахуйте підтвердження півота й затримку доставки даних.
3. З’єднайте з уже відомими записамиВикористовуйте найновіший вже відомий контекст.
4. Заморозити кандидатаБільша структура визначає зону; менша структура визначає час.
5. Виміряйте додаткову користьПорівняйте з базовим варіантом лише молодшого таймфрейму.

Кілька масштабів і кілька таймфреймів — різні підходи

Кілька масштабів — наприклад, розрахунок півотів із радіусами 2, 5 та 10 на тому самому ряді H=1. Кілька таймфреймів — окремі розрахунки барів H=1, H=4 або денних. Це не еквівалентно: агрегування чотирьох барів H=1 у H=4 втрачає їхню внутрішню послідовність. Півот H=1 з радіусом вісім не обов’язково збігається з півотом H=4 з радіусом два.

TradingView визначає таймфрейми барів [1] і пояснює запити підтверджених даних старшого таймфрейму [2]. Тут H=4 задає лише контекст, H=1 — лише сигнал входу. Не можна вибирати таймфрейм, що робить відомий результат угоди найпереконливішим.

Визначте, який контекст має внести свій вклад. Він може визначати напрямок, контрольну зону або режим волатильності. Поєднання всіх трьох одразу ускладнює визначення того, який компонент допомагає. Почніть з однієї ролі, порівняйте з базовим рівнем нижчого таймфрейму та додавайте складність лише як зареєстрований експеримент.

З’єднуйте за часом доступності, а не часом екстремуму

Кожному півоту потрібні occurred_at, confirmed_at і available_at. Останнє поле за потреби враховує доставку й обробку даних. У момент рішення t на H=1 беріть лише стан H=4 з available_at≤t. Якщо півот H=4 потребує r=2, закриття бару з екстремумом недостатньо: мають закритися ще два бари H=4.

pandas merge_asof з напрямком backward вибирає найновіший правий запис, час якого не пізніше лівого ключа [3]. З’єднуйте за available_at, групуйте за інструментом і торговим майданчиком, сортуйте час і обмежуйте вік контексту. Напрямок nearest може вибрати майбутні дані й непридатний для такого пошуку без майбутньої інформації.

Однакові часові мітки потребують явного порядку подій. Оновлення H=4 має завершитися до рішення H=1; інакше затримка обробки робить його доступним пізніше. Збіг часу на годиннику не доводить доступності. Розрізняйте останнє окреме оновлення півота H=4 та повний структурний стан із потрібними підтвердженими максимумами й мінімумами.

for each closed H1 bar t:
    h4 = latest_state(where available_at <= t, same_instrument=True)
    if h4 is None or h4.age > max_context_age: continue
    up = h4.H2 > h4.H1 + eps and h4.L2 > h4.L1 + eps
    near_support = abs(H1.low[t] - h4.last_low) <= zone_width
    if up and near_support: create_frozen_candidate(h4.anchor_ids, t)
    if candidate and H1.close[t] > candidate.micro_high + buffer:
        emit(signal_at=t, context_available_at=h4.available_at)
# Use only a micro_high confirmed before the trigger.

Приклад часу й допустимий, але збитковий сетап

Нехай бар H=4 з мінімумом закривається о 12:00, а півот потребує двох барів праворуч із закриттям о 16:00 та 20:00. Цей мінімум не можна використати для ордера H=1 о 13:00. Він потрапляє в контекст лише після отримання даних 20:00. За затримки доставки дві секунди рішення о 20:00:00 ще використовує старий стан.

Синтетичний допустимий сетап: відомі максимуми H=4 зростають 110→116, мінімуми — 100→105. Пропонована підтримка — 104.7–105.3. H=1 торкається 105.1, пізніше закривається за 106.2 вище вже підтвердженого мікромаксимуму 106. Вхід 106.3 зі стопом 104.7 дає плановий ризик 1.6 пункту; дослідницька ціль 109.5 відповідає 2R до витрат.

Невдалий шлях: пробій H=1 відбувся, але потім ціна падає нижче 104.7. Висхідний тренд H=4 описував відому історію, а не гарантував утримання 105. Перехід до H=8 після збитку, щоб назвати контекст ведмежим, означає зміну правила після відомого результату.

У тестових даних посуньте той самий сигнал H=1 на кілька секунд до й після available_at стану H=4. Допустимий контекст змінюється лише на заданій межі. Інший тест із пропущеним баром H=4 має залишати новий півот непідтвердженим, а не підставляти пізніший завершений бар без запису про пропуск.

Зафіксуйте роль та опорні точки кожної шкали

Повна конфігурація призначає більшому масштабу зону, меншому масштабу - тригер та попередньо визначену політику стоп-лоссу. Маломасштабний стоп-лосс може створити меншу початкову ризикову дистанцію, але бути вразливим до звичайних рухів усередині більшої структури. Великомасштабний стоп-лосс змінює розмір позиції та часто час утримання. Жоден з них не слід вибирати ретроспективно для кожної угоди.

При створенні кандидата зберігайте ідентифікатори опор контексту, ціни, ширину зони, час доступності контексту та вже підтверджений мікромаксимум молодшого таймфрейму. Новий контекст може скасувати кандидата без виконання за заданим правилом, але не переписувати причини попереднього сигналу.

Псевдокод — структурний ескіз: активація кандидата й оцінка сигналу повинні мати окремі часові мітки. У строгій версії з пізнішим баром вимагайте t>candidate.created_at та мікромаксимум, підтверджений не пізніше створення. Визначте випадок, коли бар створення вже перетнув максимум: відхиліть застарілого кандидата або зареєструйте окрему версію негайної активації.

Задайте TTL у минулому від створення торговому часі або барах H=1. Старий стан H=4 не стає свіжим свідченням лише тому, що він останній у записах. Сплив строку контексту, брак даних і справжній перехід до ведмежої структури потребують окремих кодів причин для вимірювання втрат можливостей від кожного правила.

Не рахуйте один і той самий об'єм повторно

Об'єм H=4 містить активність складових його стовпчиків H=1. Зростаючий обсяг H=1 та H=4, таким чином, не є двома незалежними спостереженнями. Оцінка може враховувати виконані умови, але довільні ваги не перетворюють цю оцінку на калібровану ймовірність виграшу.

Точніша ознака порівнює активність відкату H=1 зі звичайною активністю H=1 у той самий час доби, залишаючи структуру H=4 зафіксованою. Частковий обсяг H=4 порівнюйте з історичним частковим обсягом після тієї самої кількості хвилин від початку бару. Повний минулий обсяг H=4 не можна коректно порівняти з щойно відкритим поточним баром H=4.

Графік введення даних має таке ж значення, як і формула. Виправлення обсягів, затримані бари та різні визначення сесії можуть призвести до того, що той самий номінальний період H=4 агрегуватиметься інакше, ніж чотири локальні бари H=1. Зберігайте походження агрегації та порівнюйте підсумки для перевірки цілісності, перш ніж оцінювати будь-яке передбачуване підтвердження.

У тесті внеску окремих компонентів додавайте по одній ознаці обсягу до того самого набору кандидатів і правил виконання. Перевіряйте, чи зберігається покращення з урахуванням часу доби, волатильності й ліквідності; кілька позитивних умов обсягу не гарантують незалежних підтверджень.

Виміряйте додаткову цінність контексту вищих часових рамок

Порівняйте той самий детектор H=1 у трьох варіантах: без контекстного фільтра, лише напрямок H=4, напрямок H=4 плюс близькість до його зони. Правила ризику й виконання та дати тесту мають збігатися. Звітуйте про відхилені сигнали, експозицію й чисте математичне очікування: фільтр може підняти частку виграшів лише зміною складу угод.

Перевірте тестові випадки на межах H=4, під час планових закриттів, змін літнього часу й пропусків спостережень. Відтворіть дані за порядком отримання й порівняйте з пакетним часовим з’єднанням. Якщо пакетний розрахунок бачить структуру H=4 раніше, ніж відтворення, виправте з’єднання до додавання нового індикатора.

Порівняйте базовий варіант одного таймфрейму з кількома масштабами. Простіша синхронізація може пояснити значну частину позірної користі без другого календаря барів. Реєструйте пари таймфреймів і граничний вік даних як дослідницькі варіанти; зафіксуйте їх до фінального тесту.

Повідомляйте про збої в застарілому контексті окремо від збиткових угод у дійсному контексті. Перші можуть виявити проблему синхронізації або політики закінчення терміну дії; другі стосуються прогностичної цінності гіпотези. Чітка класифікація запобігає поясненню кожної втрати вибором іншої шкали.

Поширені помилки

Список перевірки перед застосуванням методу

Позначайте кожен пункт після перевірки на власних даних. Прогрес зберігається в цьому браузері й не засвідчує прибутковість стратегії.

• Призначте кожній шкалі фіксовану роль.
• Виключити незавершені значення для вищих часових інтервалів.
• Дочекайтеся всіх правих барів підтвердження півота старшого таймфрейму.
• Здійснити зворотне з'єднання за допомогою available_at.
• Визначити порядок обробки для однакових часових позначок.
• Не використовуйте контекст старший за дозволений строк.
• Не рахуйте вкладений торговий обсяг як незалежне свідчення.
• Пакетний розрахунок і відтворення за порядком отримання даних мають збігатися.

Джерела дослідження

Кожне джерело підтверджує визначення або докази, описані поруч. Псевдокод, штучні приклади та запропоновані параметри потребують окремої перевірки.

1. Pine Script: TimeframesTradingView. Прочитано визначення таймфреймів та одиниць. Перевірено: 2026-10-11.
2. Other timeframes and dataTradingView. Прочитано приклади запиту підтверджених даних старшого таймфрейму. Перевірено: 2026-10-11.
3. pandas.merge_asofpandas. Прочитано опис backward-зіставлення, допуску й поведінки точного збігу. Перевірено: 2026-10-11.

Пов’язані методи