Индикаторами я особо не занимаюсь. Пишу больше торговые алгоритмы для себя. Понадобилось написать индюк. Индюк будет брать данные из другого индюка и на основании его рассчитывать уровни. Я подумал, придумал свой вариант реализации. Но было влом его реализовывать. Подумал чутка где посмотреть пример реализации. Вспомнил, что индюк МАКД базируется на 2 индюках МА. Заглянул в него. Увидел несколько не логичных моментов не в логике, а в плане реализации самого кода. Но их обсуждать я не буду т.к. не нужно. Но есть 1 момент странный, который меня озадачил. Вот он:
Для чего это условие?
Как по мне это какой-то неадекватный подход. Не может быть просчитано больше баров чем есть на графике. А если это может быть значит косяк в реализации этого момента связанного с запоминанием prev_calculated вообще.Интересно услышать мнение тех, кто это понимает.
Я ради интереса переписал МАКД и он стал меньше в раза 2, чем был. Удивляюсь, нафига так раздувать код.. Либо разработчики приучают к процедурному принципу программирования, либо тот кто писать пишет только процедурно, а "ломать себя" не хочет..
Это для того, чтоб не пересчитывать на каждом тике - это сильно затратно. Вот именно этим и занимается prev_calculated > rates_total, чтобы пересчитывает на новом баре
Это для того, чтоб не пересчитывать на каждом тике - это сильно затратно. Вот именно этим и занимается prev_calculated > rates_total, чтобы пересчитывает на новом баре
Виталий, я знаю для чего он нужен. Это как-бы базовая часть. Вопрос в том, что prev_calculated не может быть больше rates_total. Т.е. условие:
prev_calculated > rates_totalНикогда не будет истинным..
Виталий, я знаю для чего он нужен. Это как-бы базовая часть. Вопрос в том, что prev_calculated не может быть больше rates_total. Т.е. условие:
Никогда не будет истинным..Просмотрите внимательней, и распринтуйте значения на новом баре
Ну так...:
int OnCalculate(const int rates_total, const int prev_calculated, const datetime &time[], const double &open[], const double &high[], const double &low[], const double &close[], const long &tick_volume[], const long &volume[], const int &spread[]) { //--- check for data Print("rates_total = ", rates_total); Print("prev_calculated = ", prev_calculated); if(rates_total < i_signalSMA || i_fastEMA > i_slowEMA) return 0;
В журнале вижу:
2018.08.25 19:31:01.481 MACD_Original (GBPUSD,H4) rates_total = 32067 2018.08.25 19:31:01.481 MACD_Original (GBPUSD,H4) prev_calculated = 0 2018.08.25 19:31:01.483 MACD_Original (GBPUSD,H4) rates_total = 32067 2018.08.25 19:31:01.483 MACD_Original (GBPUSD,H4) prev_calculated = 32067
Вывод из всего этого, что я прав. Эта проверка = дичъ. Причём редкостная, которая учит новичков не правильной и кривой логике.
А логика в чём? По прямой логике такого быть не может т.к. расчёт значений буферов индикатора происходит по циклу присутствующих на графике баров соответствующего ТФ а не по хз чему.
Я в своих индикаторах пользуюсь подобной функцией:
//+---------------------------------------------------------------------------------------------------------------------------------------------------------------+ //| Определение индекса бара, с которого необходимо производить перерасчет | //+---------------------------------------------------------------------------------------------------------------------------------------------------------------+ void getRecalcIndex(const int barsCount, // Количество пришедших баров таймфрейма открытого графика const int countedBars) { // Количество уже обработанных баров таймфрейма открытого графика //--- if (countedBars != 0) { return barsCount - countedBars; } else { return barsCount; } }
Работает замечательно. И пользоваться удобнее гораздо.
На новом баре наоборот -
prev_calculated < rates_total
На новом баре наоборот -
Вот из тестера в добавок принт:
2018.08.25 19:40:11.090 2009.01.01 00:00:00 rates_total = 73823 2018.08.25 19:40:11.090 2009.01.01 00:00:00 prev_calculated = 0 2018.08.25 19:40:13.139 2009.01.26 04:34:00 rates_total = 73824 2018.08.25 19:40:13.139 2009.01.26 04:34:00 prev_calculated = 73823 2018.08.25 19:40:13.161 2009.01.26 04:34:20 rates_total = 73824 2018.08.25 19:40:13.161 2009.01.26 04:34:20 prev_calculated = 73824 2018.08.25 19:40:13.184 2009.01.26 04:34:40 rates_total = 73824 2018.08.25 19:40:13.184 2009.01.26 04:34:40 prev_calculated = 73824 2018.08.25 19:40:13.206 2009.01.26 04:34:59 rates_total = 73824 2018.08.25 19:40:13.206 2009.01.26 04:34:59 prev_calculated = 73824 2018.08.25 19:40:13.228 2009.01.26 04:35:00 rates_total = 73825 2018.08.25 19:40:13.228 2009.01.26 04:35:00 prev_calculated = 73824 2018.08.25 19:40:13.250 2009.01.26 04:35:20 rates_total = 73825 2018.08.25 19:40:13.250 2009.01.26 04:35:20 prev_calculated = 73825 2018.08.25 19:40:13.273 2009.01.26 04:35:40 rates_total = 73825
prev_calculated не может быть больше rates_total
Теоретически может, если количество баров в окне ограничено и rates_total будет уменьшено до заданного значения.
Теоретически может, если количество баров в окне ограничено и rates_total будет уменьшено до заданного значения.
Зачем это?
Все просто, горячие эстонские парни: первое условие выделяет диапазон недопустимых значений, а второе - диапазон рабочих значений.
В первом случае пересчитывается все, а во втором - только то, что не было обработано ранее.
ЗЫ: А отчего Вас не заинтересовала конструкция prev_calculated < 0 ?Как по мне это какой-то неадекватный подход. Не может быть просчитано больше баров чем есть на графике. А если это может быть значит косяк в реализации этого момента связанного с запоминанием prev_calculated вообще.Интересно услышать мнение тех, кто это понимает.
Полагаю - это рудимент. Раньше, вероятно, при каких-то условиях эта проверка приводила к полному пересчету индикатора. Сейчас достаточно prev_calculated <= 0. По крайней мере я пишу так и проблем с этим не замечал.
Теоретически может, если количество баров в окне ограничено и rates_total будет уменьшено до заданного значения.
Не может, т.к. настройка количества баров в окне применяется только после перезагрузки терминала.
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Вы принимаете политику сайта и условия использования
Индикаторами я особо не занимаюсь. Пишу больше торговые алгоритмы для себя. Понадобилось написать индюк. Индюк будет брать данные из другого индюка и на основании его рассчитывать уровни. Я подумал, придумал свой вариант реализации. Но было влом его реализовывать. Подумал чутка где посмотреть пример реализации. Вспомнил, что индюк МАКД базируется на 2 индюках МА. Заглянул в него. Увидел несколько не логичных моментов не в логике, а в плане реализации самого кода. Но их обсуждать я не буду т.к. не нужно. Но есть 1 момент странный, который меня озадачил. Вот он:
Для чего это условие?
Как по мне это какой-то неадекватный подход. Не может быть просчитано больше баров чем есть на графике. А если это может быть значит косяк в реализации этого момента связанного с запоминанием prev_calculated вообще.Интересно услышать мнение тех, кто это понимает.
Я ради интереса переписал МАКД и он стал меньше в раза 2, чем был. Удивляюсь, нафига так раздувать код.. Либо разработчики приучают к процедурному принципу программирования, либо тот кто писать пишет только процедурно, а "ломать себя" не хочет..