Переработка конвертера графиков
С этим модулем в терминале есть целый ряд проблем: невозможно построить кастомные таймфреймы с произвольным значением из-за странной логики, которая требует кратности таймфрейма 24 часам (суткам) и 168 часам (неделе). При попытке построить, например, ТФ H15 или H32 вы получите не график, а сплошную ошибку.
Только отчасти работают все нестандартные типы графиков, как-то рейнжи, тиковые и прочие, т.к. они строго ограничены в своем построении сутками: в конце дня расчет прерывается и вместо полноценно сформированной по заданным условиям свечи формируется "огрызок" - то, что получилось между предыдущей полноценной свечой и концом дня, и далее начинается построение новой свечи.
Если в течение всего дня условия так и не наступили, то вместо, например, рейнж бара указанного размера нарисуется просто дневная свеча. В итоге график строится корректно лишь местами - на тех участках цены, где было достаточно волатильности, а где не было, там получатся никакие не рейнж бары, а произвол.
Каким на мой взгляд должен быть правильный конвертер таймфреймов:
1) отсутствуют ограничения на предельный размер таймфрейма. Можно построить 2 недели, 3 месяца, полгода и так далее. Хоть в одну свечу можно график ужать
2) есть возможность выбрать базовый таймфрейм (донор) для построения более старшего. То есть когда можно, например, построить range график из тиков, а можно также из секунд или минут. Это решает сразу два вопроса: позволит сэкономить ресурсы (не нужно всегда грузить миллионы тиков) и уберет эффект "забора", который периодически возникает на экстремально быстрых движениях цены при построении графиков из тиков.
3) отсутствует требование по целостной кратности по отношению к каким-то старшим таймфреймам, как сейчас таймы должны кратно и нацело умещаться в сутки (24 часа) и неделю (168 часов), из-за чего в конце дня построение обрывается и в результате на выходе - рванина. То есть можно строить любые таймы: 15 часов, 32 часа и так далее. Так будут получаться корректные как временные, так и все прочие графики
Более подробное описание проблем и примеров правильных решений - в переписке с саппортом.
Log in to comment and vote
Comments3
ATAS user
Apr 5, 2024
'сброс' свечек в начале каждой сессии обусловлен требованием к тому, чтобы при открытии графиков с любой глубиной истории, эта история не перерисовывалась. Если же не сбрасывать графики в начале сессий, то построение будет сильно зависеть от начальной точки.
mdmtr
Apr 5, 2024
Если сбрасывать, то полученный график представляет собой хаос, смесь из правильных и совершенно случайных свечей. Это же еще хуже.
У этой проблемы совершенно точно есть приемлемое решение, примером тому - ряд платформ, где построение рейнж и прочих подобных графиков не ограничено сутками. Есть же варианты, например можно увеличить таймфрейм, на котором ищется точка отсчета для построений, со дня до недели или месяца, ну день - это совсем мало. Или можно дать возможность пользователю самому выбирать эту точку через параметр глубины загрузки истории. Это как минимум позволит сделать перерисовку редкой и контролируемой, а не произвольной.
Я могу в качестве образцов логики предоставить код из другой платформы, не знаю правда, насколько уместно сделать это прямо здесь, да и очевидно, что разработчики терминала владеют вопросом явно лучше меня) Но если надо и поможет делу, то не вопрос.
mdmtr
Apr 5, 2024
Когда отвечал, еще не заметил, что предложение уже отклонено. Это очень печально, потому что целый, крайне важный модуль терминала работает очевидно ошибочным образом, а предлог, чтобы сохранить его в нынешнем виде и ничего не менять, просто несостоятелен и абсолютно точно не является сколько-нибудь серьезным препятствием для исправления некорректной работы алгоритма.