В каких случаях есть смысл держать часть кода робота в индикаторе? - страница 34

Новый комментарий
 
TheXpert:

Разоблачение заблуждения №1: можно обойтись без IndicatorCounted()

Индюк с оным:

Без оного, по принципу hrenfx

Далее накидываем индюки на график и эмулируем потерю связи во время работы автомата. Результат:




Все так. Поэтому, я избегаю пользоваться возможностями, которые не пригодятся в дальнейшем (при разработке эксперта).

Не верю в электричество и предпочитаю все делать сам. А эта функция мне непонятна.

 
sergeev:


А исследования и проверки по этой догадке выложить можете?

Всего несколько экспериментов провел с обрывом связи. Проводить полный анализ кала разработчиков не стал. Делать это и противно и долго (разрыв надо делать не на минуту-другую, а хотя бы на десяток-другой). Мой вариант советника обрабатывает кратковременные обрывы связи без проблем. Однако, исследования показали, что крактовременные (для M1) - это не часы, а минуты (< 10).

Вы можете полностью раскопать эту тему простыми экспериментами. Я еще не могу утверждать на 100%. ВОзможно, надо вначале советника вызывать не пустой индикатор, а индикатор с вызовом IndicatorCounted().

Пришел в голову быстрый способ исследовать: запустить сразу несколько терминалов (потребуется меньше пяти) и на каждом свой вариант исследования. Оборвать связь на час, а потом восстановить. Получите сразу несколько различных вариантов. Из них сложится верная картина.

P.S. Надо именно разные терминалы, а не разные чарты. Чтобы исключить вариант, что IndicatorCounted() считается один раз для всех индикаторов в терминале.

P.P.S. А еще именно работа этого дерьма была сильно изменена в билдах > 380. И, судя по отзывам, еще неоднократно будет меняться. Так что исследование проводить почти бессмысленно. Спросить разработчиков надо напрямую, что происходит с индикатором (в котором есть вызов IndicatorCounted()) во время первого тика после длительного обрыва связи.

P.P.P.S. Спросил.

 
Integer:


Не смешите. Вы просто еще не научились писать индикаторы.

После такой ереси:

могли бы вообще воздержаться от своего мнения в этой теме.


Ну, кто и что научился писать, думаю, со стороны будет виднее, насчёт ереси - уровень вашего мышления, надо полагать, по всем признакам лихо смахивает на логику религиозных фанатиков, с коими спорить бесполезно и абсолютно не нужно. Даже с такой ересью эксперты работают в три раза быстрее. Но выкорячиваться, кому-то и что-то доказывать, а тем более оправдываться у меня лично нет никакого желания. Квалификация моего ума слишком дорого стоит, чтобы её так убого и бездарно тратить.
 
Уважаемых мэтров (всех) хотелось бы попросить уважительнее относиться друг к другу. Чему Вы молодежь научите?
 
TheXpert:

Разоблачение заблуждения №1: можно обойтись без IndicatorCounted()

Индюк с оным:

Без оного, по принципу hrenfx

Далее накидываем индюки на график и эмулируем потерю связи во время работы автомата. Результат:




ИМХО: Сравнение не корректно: алгоритм с рекурсией при прочих равных всегда будет выполняться медленней. Для чистоты эксперимента неплохо и в индикаторе и в советнике юзать один и тот же алгоритм рассчета.

Что мешает в советнике сделать учет последнего рассчитанного бара и при разности текущего количества баров с последним рассчитанным более, чем на 1 пересчитывать с соответствующего места, как это делает индикатор ?

 
GODZILLA:

Ну, кто и что научился писать, думаю, со стороны будет виднее, насчёт ереси - уровень вашего мышления, надо полагать, по всем признакам лихо смахивает на логику религиозных фанатиков, с коими спорить бесполезно и абсолютно не нужно. Даже с такой ересью эксперты работают в три раза быстрее. Но выкорячиваться, кому-то и что-то доказывать, а тем более оправдываться у меня лично нет никакого желания. Квалификация моего ума слишком дорого стоит, чтобы её так убого и бездарно тратить.

Это вот с этой штукой 

//---- ЭМУЛЯЦИЯ ИНДИКАТОРНЫХ БУФЕРОВ
  int NewSize = iBars(symbol, timeframe);
  //----  Проверка на смену нулевого бара
  if(ArraySize(Ind_Buffer0) < NewSize)
    {
      //---- Установить прямое направление индексирования в массиве 
      ArraySetAsSeries(Ind_Buffer0, false);
      ArraySetAsSeries(Ind_Buffer1, false);
      ArraySetAsSeries(Ind_Buffer2, false);
      //---- Изменить размер эмулируемых индикаторных буферов 
      ArrayResize(Ind_Buffer0, NewSize); 
      ArrayResize(Ind_Buffer1, NewSize); 
      ArrayResize(Ind_Buffer2, NewSize); 
      //---- Установить обратное направление индексирования в массиве 
      ArraySetAsSeries(Ind_Buffer0, true);
      ArraySetAsSeries(Ind_Buffer1, true);
      ArraySetAsSeries(Ind_Buffer2, true); 
    } 
//----

у вас эксперты быстро работают? Ну и кто здесь фанатик после такого? Давно проверено, можете воспользоваться поиском по форуму.

 
granit77:
Уважаемых мэтров (всех) хотелось бы попросить уважительнее относиться друг к другу. Чему Вы молодежь научите?

Лично меня совсем не оскорбляет обвинение меня в религиозном фанатизме, потому что я очень хорошо знаю кто я и что я. К тому же такое обвинение является хорошим показателем уровня мышления на той стороне, исчерпывающим показателем.
 
GODZILLA:
Ну, кто и что научился писать, думаю, со стороны будет виднее

Ага, видно отлично. Ваш авторитет в моих глазах падает в три раза быстрее чем прежде :)

VladislavVG:

ИМХО: Сравнение не корректно: алгоритм с рекурсией при прочих равных всегда будет выполняться медленней. Для чистоты эксперимента неплохо и в индикаторе и в советнике юзать один и тот же алгоритм рассчета.

Сравнение корректно, ибо сделано не для сравнения скорости а для того, чтобы наглядно показать неправильность работы.

Что мешает в советнике сделать учет последнего рассчитанного бара и при разности текущего количества баров с последним рассчитанным более, чем на 1 пересчитывать с соответствующего места, как это делает индикатор ?

А Вы попробуйте.

hrenfx:

Советник на первом тике после появления связи ведет совсем не так, как индикатор, полученный из советника.

Выше привел скрин, где видно, что после разрыва связи сравнивается советник (не индикатор из советника) с iCustom. Там обрыв связи проходит без проблем.

Вы снова неправы. Советник ведет себя аналогично. Вы просто не можете верно проанализировать Ваши же логи. Я уже объяснял в чем ошибка, повторяться не хочу.

Хинт: посмотрите несколько значений после разрыва.

granit77:

Уважаемых мэтров (всех) хотелось бы попросить уважительнее относиться друг к другу. Чему Вы молодежь научите?

Мэтры не должны нести ереси, это раз, и должны уметь признавать ошибки, это два.
 
TheXpert:

Вы снова неправы. Советник ведет себя аналогично. Вы просто не можете верно проанализировать Ваши же логи. Я уже объяснял в чем ошибка, повторяться не хочу.

Хинт: посмотрите несколько значений после разрыва.

Да, я привел скрин только для одного значения после разрыва. Конечно, видел все значения и дальше (обманом, а тем более таким глупым, не занимаюсь). Совпадение полное (в скрин не попало).

К сожалению, разработчики до сих пор не понимают возможную пользу от IndicatorCounted() для советников (судя по их ответу).

Индикатор и советник на первом тике после разрыва (особенно длительного) ведут себя не одинаково. При желании, вы легко это проверите.

 
Integer:

Лично меня совсем не оскорбляет обвинение меня в религиозном фанатизме, потому что я очень хорошо знаю кто я и что я. К тому же такое обвинение является хорошим показателем уровня мышления на той стороне, исчерпывающим показателем.

Ну а ваше мышление вы считаете адекватным и нефанатичным, если на то пошло? Мало того что вы не смогли доказать свою гипотезу-верование о том что тот же самый код в индикаторе всегда будет быстрее чем в советнике, а вместо этого затеяли совершенно непонятное и бессмысленное соревнование (это кстати вышло хорошо так как позволило наткнутся на интересное решение обрыва связи в советнике). Кстати нигде на сайте не встречал утверждения разработчиков что код советника предпочтительно выносить в индикатор для ускорения быстродействия, так что подобное утверждение звучит с вашей стороны по меньшей мере странно, думаю что вы согласитесь с этим.

Моё же предположение основывалось на простой логике что обращение к внешней функции с передачей копии буфера и параметров требует большего времени чем без него, почему вы стали это отрицать, непонятно.

1...272829303132333435363738
Новый комментарий
Причина обращения: