Нет ! , не чревато - если бары чарта ведут себя таким же образом - синхронно. Другими словами - если кольцевые буферы (пусть даже разные по размеру) всегда (насильственно) используют флаг AsSeries - массовых неприятностей у юзера не ожидается.
// В этом случае удобно будет сделать все предоставляемые юзеру исторические буферы - индикаторными (т.е. кольцевыми, с AsSeries=true).
В этом варианте:
(1) есть внутренне представление индикаторных и ценовых массивов (на вашей стороне) : индексация слева направо (AsSeries==false), размеры юзера не касаются, да и вообще "вход воспрещён".
И (2) есть сторона юзера - все буферы кольцевые (в реализации. юзер видит виртуальный линейный массив), индексация справа налево (AsSeries==true) и размер задан юзером.
Какие здесь сносы юзерской крыши? Никаких. При выходе за заданный диапазон - стандартная реакция Array out of range.
Трудности (немалые, если честно) только у вас. Но! Учитывая универсальность схемы - напрячься придётся только один раз. И пофиксить все "красивые глюки" в зародыше, при отладке беты. После чего - всеобщее счастье и очень экономная конструкция.
Хорошая идея. Я - за. Но она не отменяет внедрение кольцевой схемы, а просто хорошо дополняет.
Опишу условия теста:
история баров идет как заказано от 2000.01.01 до 2012.01.01 на M1
эксперт работает с короткими индикаторами по 10 000 баров, история индикаторов подрезается, чтобы не вылезать за пределы 10 000 - 15000 баров
В результате автоматического подрезания индикатора мы:
портим кумулятивность (это можно стерпеть, хотя будет дребезг результатов, который приведет к неминуемому - "да в МТ5 даже индюки глючат!")
теряем скорость на неминуемом сдвиге истории индикаторов (memcopy дорогой, хотя объем памяти еще дороже)
реально сносим крышу программистам, которые умудрятся закладываться на запомненные счетчики (это лечится личной аккуратностью)
история баров идет как заказано от 2000.01.01 до 2012.01.01 на M1
эксперт работает с короткими индикаторами по 10 000 баров, история индикаторов подрезается, чтобы не вылезать за пределы 10 000 - 15000 баров
В результате автоматического подрезания индикатора мы:
1.
портим кумулятивность (это можно стерпеть, хотя будет дребезг результатов, который приведет к неминуемому - "да в МТ5 даже индюки глючат!")
Да, это терпимо. Вряд ли это приведёт к массовому недовольству, скорее наоборот - экономия очень обрадует. Никто ж не запрещает тратить память устанавливая огромный MaxBar.
// Вот глючат же индикаторы из-за пропуска баров! Вот уж где недовольство оправдано всерьёз!
// Дык вы даже это терпите... :) Ну и нам приходится... :(
2.
теряем скорость на неминуемом сдвиге истории индикаторов (memcopy дорогой, хотя объем памяти еще дороже)
Вот как раз нет и нет! Кольцевая схема как раз и приводит к огромной экономии на копировании при сдвигах по истории. Фактически при сдвигах на один бар (N баров) , приходится копировать ровно одно значение (N значений). Затраты же (юзерские) на виртуализацию индекса ничтожны. Фактически их даже трудно обнаружить при стресс тестах (остаток от деления вычисляется процессором за один такт + смещение виртуального начала буфера при каждом сдвиге по истории - ещё пару тактов). Так что скорость мы практически не теряем. Невозможно обнаружить это замедление, настолько оно мало. И на фоне гигантской экономии памяти эти потери несоизмеримы с выигрышем.
3.
реально сносим крышу программистам, которые умудрятся закладываться на запомненные счетчики (это лечится личной аккуратностью)
Я даже не понял о чём тут речь. Возможно просто здоров в этом месте.
Почему-то столько плясок и воплей вокруг захлёбывающихся на unlimited bars индикаторов, но ни слова - о пляшущих графических объектах. Попробуйте на Unlimited построить, например, супербольшие Вилы Эндрюса (на MN1, например), потом ограничьте в настройках терминала число баров, сходите на младшие таймфреймы и отмотайте к точкам привязки. Некоторые из них будут в грандиозном временнОм отрыве от экстремумов (это притом, что вилы всеми тремя точками лежат исключительно в области настоящих M1-баров, не заходя за границу подложных от более высоких таймфреймов!). А всё почему? Видимо, потому, что для расчёта точного M1-значения некоторых точек автопривязки не хватило исторических данных на M1. Хотя причём тут исторические данные?! Их-то, может, и хватило, а вот отображаемых в окне баров - нет, поэтому и сдвиги. То есть некоторые точки "сами толком не знают, где они лежат".
Хоть бы кто у себя проверил, а то, может, у меня одного такая свистопляска...
В момент формирования нового бара если считать значения Open и Close предыдущих баров (например 10 предыдущих баров), а потом спустя 5 секунд получить их снова, то некоторые из этих значений отличаются и потом если их получать пока новый бар формируется то все нормально, но вот в первые несколько секунду почему-то эти значения другие.
Надеюсь я понятно объяснил.
Не подскажите, прежде чем считывать значения баров Open и Close от начала нового бара нужно ставить задержку более 5 секунд?
Вот пример работы:
Сверху правильно сработала после задержки, снизу сразу после появления нового бара с ошибкой, а справа эталон для 6-й строки.
Язык программирования MQL5 позволяет решать задачи на совершенно новом уровне. Даже те задачи, которые уже вроде имеют решения, благодаря объектно-ориентированному программированию могут подняться на качественно новый уровень. В данной статье специально взят простой пример проверки появления нового бара на графике, который был преобразован в достаточно мощный и универсальный инструмент. Какой? Читайте в статье.
Не пойму. Толи у меня проблемы, толи не у меня. В формуе при нажатии на "ответить" в появившемся окне редактора дублировалось в виде цитаты соответствующий пост. Сейчас пару дней назад такая возможность пропала. Открывается пустое окно. Пробовал в Опере и ИЕ.
3. А вот он и язь! :
Нет ! , не чревато - если бары чарта ведут себя таким же образом - синхронно. Другими словами - если кольцевые буферы (пусть даже разные по размеру) всегда (насильственно) используют флаг AsSeries - массовых неприятностей у юзера не ожидается.
// В этом случае удобно будет сделать все предоставляемые юзеру исторические буферы - индикаторными (т.е. кольцевыми, с AsSeries=true).
В этом варианте:
(1) есть внутренне представление индикаторных и ценовых массивов (на вашей стороне) : индексация слева направо (AsSeries==false), размеры юзера не касаются, да и вообще "вход воспрещён".
И (2) есть сторона юзера - все буферы кольцевые (в реализации. юзер видит виртуальный линейный массив), индексация справа налево (AsSeries==true) и размер задан юзером.
Какие здесь сносы юзерской крыши? Никаких. При выходе за заданный диапазон - стандартная реакция Array out of range.
Трудности (немалые, если честно) только у вас. Но! Учитывая универсальность схемы - напрячься придётся только один раз. И пофиксить все "красивые глюки" в зародыше, при отладке беты. После чего - всеобщее счастье и очень экономная конструкция.
Хорошая идея. Я - за. Но она не отменяет внедрение кольцевой схемы, а просто хорошо дополняет.Опишу условия теста:
В результате автоматического подрезания индикатора мы:
Опишу условия теста:
В результате автоматического подрезания индикатора мы:
1.
Да, это терпимо. Вряд ли это приведёт к массовому недовольству, скорее наоборот - экономия очень обрадует. Никто ж не запрещает тратить память устанавливая огромный MaxBar.
// Вот глючат же индикаторы из-за пропуска баров! Вот уж где недовольство оправдано всерьёз!
// Дык вы даже это терпите... :) Ну и нам приходится... :(
2.
Вот как раз нет и нет! Кольцевая схема как раз и приводит к огромной экономии на копировании при сдвигах по истории. Фактически при сдвигах на один бар (N баров) , приходится копировать ровно одно значение (N значений). Затраты же (юзерские) на виртуализацию индекса ничтожны. Фактически их даже трудно обнаружить при стресс тестах (остаток от деления вычисляется процессором за один такт + смещение виртуального начала буфера при каждом сдвиге по истории - ещё пару тактов). Так что скорость мы практически не теряем. Невозможно обнаружить это замедление, настолько оно мало. И на фоне гигантской экономии памяти эти потери несоизмеримы с выигрышем.
3.
Эххх, лицорука...
Почему-то столько плясок и воплей вокруг захлёбывающихся на unlimited bars индикаторов, но ни слова - о пляшущих графических объектах. Попробуйте на Unlimited построить, например, супербольшие Вилы Эндрюса (на MN1, например), потом ограничьте в настройках терминала число баров, сходите на младшие таймфреймы и отмотайте к точкам привязки. Некоторые из них будут в грандиозном временнОм отрыве от экстремумов (это притом, что вилы всеми тремя точками лежат исключительно в области настоящих M1-баров, не заходя за границу подложных от более высоких таймфреймов!). А всё почему? Видимо, потому, что для расчёта точного M1-значения некоторых точек автопривязки не хватило исторических данных на M1. Хотя причём тут исторические данные?! Их-то, может, и хватило, а вот отображаемых в окне баров - нет, поэтому и сдвиги. То есть некоторые точки "сами толком не знают, где они лежат".
Хоть бы кто у себя проверил, а то, может, у меня одного такая свистопляска...
Заметил одну странность!
В момент формирования нового бара если считать значения Open и Close предыдущих баров (например 10 предыдущих баров), а потом спустя 5 секунд получить их снова, то некоторые из этих значений отличаются и потом если их получать пока новый бар формируется то все нормально, но вот в первые несколько секунду почему-то эти значения другие.
Надеюсь я понятно объяснил.
Не подскажите, прежде чем считывать значения баров Open и Close от начала нового бара нужно ставить задержку более 5 секунд?
Вот пример работы:
Сверху правильно сработала после задержки, снизу сразу после появления нового бара с ошибкой, а справа эталон для 6-й строки.
Возможно проблема в несинхронизированности, новый бар желательно отслеживать по всем используемым инструментам.
Да, Вы оказались правы, спасибо!
Аналогично, опера.
Аналогично, опера.
У меня FF 8, таже проблема