Немного удивлен :) Решил поделиться и задать НЕ риторический вопрос. - страница 7
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Смысл не в тестере, ещё раз! не в тестере, а в реальных условиях, где происходит докачка истории и обрывы связи
Если в реальных условиях произойдет сброс и пересчет индикатора, ничего страшного в этом нет.
Еще один вопрос назрел. Здесь большенству заняться нечем, чтоли? Сидят и переписывают штатный функционал терминала на mql5. Наверно скоро кто-то напишет на mql5 целый терминал.
Если в реальных условиях произойдет сброс и пересчет индикатора, ничего страшного в этом нет.
Еще один вопрос назрел. Здесь большенству заняться нечем, чтоли? Сидят и переписывают штатный функционал терминала на mql5. Наверно скоро кто-то напишет на mql5 целый терминал.
Конечно ничего страшного. Когда у тебя висят 100 ZUP в одном терминале (это я просто для примера), ничего страшного...
То же вопрос назрел. Все любят рассуждать только со своей колокольни, почему?
Вот здесь используется не один индикатор:
Влияние штатной функции ИндикаторКаунт просто убийственно для него (я лично проверял). А при реализации в виде классов разрывы связи вообще фиолетовы
P.S. Для одной MA это конечно ничего страшного
Конечно ничего страшного. Когда у тебя висят 100 ZUP в одном терминале (это я просто для примера), ничего страшного...
То же вопрос назрел. Все любят рассуждать только со своей колокольни, почему?
Всегда кому-то хочется больше,чем можется. Только зачем так много?
Обойти проблему сброса в индикатора можно пятью строчками кода. Запоминать время первого бара, если оно изменилось, нужен полный пересчет. Запоминать номер последнего бара, в случае сброса продолжать пересчет от этого бара, и все дела.
Со своей колокольни, не побоюсь сказать, ничего не подтверждая аргументами, что моя колокольня правильнее и точка.
Всегда кому-то хочется больше,чем можется. Только зачем так много?
Обойти проблему сброса в индикатора можно пятью строчками кода. Запоминать время первого бара, если оно изменилось, нужен полный пересчет. Запоминать номер последнего бара, в случае сброса продолжать пересчет от этого бара, и все дела.
Со своей колокольни, не побоюсь сказать, ничего не подтверждая аргументами, что моя колокольня правильнее и точка.
Не будьте столь самоуверены в себе. Научитесь не только слушать, но и слышать других.
История может изменится в середине и Ваш подход при этом полетит в тар-тарары. Спросите у Рената по этому поводу.
Ошибка в IndicatorCounted() в МТ4, которую исправили с моей наводки только сейчас, отправляла даже правильно написанные индикаторы в утиль (особенно ЗигЗаг на малых ТФ).
Не говоря уж о Вашем подходе к этому делу....
Даже спорить с Вами не буду, потому что Вы в данной ситуации совершенно неправы.
Не будьте столь самоуверены в себе. Научитесь не только слушать, но и слышать других.
История может изменится в середине и Ваш подход при этом полетит в тар-тарары. Спросите у Рената по этому поводу.
Ошибка в IndicatorCounted() в МТ4, которую исправили с моей наводки только сейчас, отправляла даже правильно написанные индикаторы в утиль (особенно ЗигЗаг на малых ТФ).
Даже спорить с Вами не буду, потому что Вы в данной ситуации совершенно неправы.
Добавьте еще пару проверок в момент сброса, увеличилось ли количество баров, но время бара не изменилось или добавлено больше одного бара.
Насчет самоуверенности, все наоборот, это вы тут все особоуверенные, уже третий, кто считает себя круче MQ.
Добавьте еще пару проверок в момент сброса, увеличилось ли количество баров, но время бара не изменилось или добавлено больше одного бара.
Насчет самоуверенности, все наоборот, это вы тут все особоуверенные, уже третий, кто считает себя круче MQ.
Какие проверки? Ситуация. Появляется новый тик на старом баре. Ничего не поменялось - ни общее количество баров, ни время открытия последнего бара, но при этом
переписались 30 последних баров (у них изменились, пусть и незначительно, цены открытия/закрытия, максимум, минимум).
Что Вы будете делать со своим алгоритмом? Ничего! Он просто не сработает в данной ситуации. И индикатор будет полностью некорректен!
Что было в МТ4 до последних билдов - он в 70% случаев то же никак не реагировал на эту ситуацию.
Но после анализа данной проблемы всё исправили, вот Стинго пишет именно по этому поводу: https://www.mql5.com/ru/forum/132422
Я не считаю себе круче других. Наоборот активно помогаю исправлять все баги в МТ4 и МТ5 - спросите любого представителя MetaQuotes.
А то, что некоторые механизмы реализованы не так как хочется - на всех не угодишь....
Это интересный вопрос, что считать правильным, что было до или что было после корректировки истории. Если не возвращаться к подкорректированным барам, индиктор продолжит работать так, как буд-то история не корректировалась. У hrenfx - именно такое отношение к этому вопросу, он считает правильными старую историю, у вас противоположное.
Есть еще мнение, что нужно пользоваться только штатной prev_calculated, безвариантно. Если тяжелый индикатор, ограничить количество обсчитываемых на запуске баров. Остальное - танцы с бубном, результат сомнителен.
Это интересный вопрос, что считать правильным, что было до или что было после корректировки истории. Если не возвращаться к подкорректированным барам, индиктор продолжит работать так, как буд-то история не корректировалась. У hrenfx - именно такое отношение к этому вопросу, он считает правильными старую историю, у вас противоположное.
Есть еще мнение, что нужно пользоваться только штатной prev_calculated, безвариантно. Если тяжелый индикатор, ограничить количество обсчитываемых на запуске баров. Остальное - танцы с бубном, результат сомнителен.
Каждый для себе решает, что считать правильным, а что нет. Для ЗигЗага вышеописанная ситуация убийственна полностью. Для МА - будет отклонение на 0,0001 в её значении...
Мнение может быть зачастую навязано (я не говорю, что это не правильно).
В общем предлагаю на этом закончить полемику. Теоретические размышления ни к чему не приведут..
В тестере кастомная оптимизация расчетов индикаторов будет работать идеально, но в терминале могут появиться неприятные сдвиги истории и неправильные расчеты.
Кстати, в мт5 используется очень эффективный и мгновенный контроль целостности исторической базы в рилтайме, что увеличивает частоту сброса prev_counted в ноль. Если не учитывать этот счетчик правильно, а заниматься собственными оптимизациями, то можно словить много проблем в реальной работе. Апдейты минутной истории доставляются мгновенно на терминалы самим сервером.
В тестере кастомная оптимизация расчетов индикаторов будет работать идеально, но в терминале могут появиться неприятные сдвиги истории и неправильные расчеты.
И я про это.
Может Вы всё таки подумаете, как сбрасывать prev_counted не в ноль, а до первого не изменённого значения?