Индикаторы: Liner regression

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

Liner regression:

Линейная регрессия

Liner regression

Автор: Mladen Rakic

 
Automated-Trading:

Регрессия лайнера:

Автор: Младен Ракич

 
Automated-Trading:

Регрессия лайнера:

Автор: Младен Ракич

Похоже, что в вашей версии та же математика, что и в вашей:

https://www.mql5.com/ru/code/429

Я прогнал обе для периода 20 на NZDUSD,D1, и они точно совпадают.

Различия:

  • Вы выделяете цветом наклон.

  • У него есть возможность "сдвигать" бары и точки.

  • У вашего есть возможность переключать APPLIED_PRICE.
 
Anthony Garot:

Ваша версия, похоже, соответствует математике:

https://www.mql5.com/ru/code/429

Я прогнал обе версии для периода 20 на NZDUSD,D1, и они точно совпадают.

Различия:

  • В твоем цветовое кодирование наклона.

  • У него есть возможность "сдвигать" бары и точки.

  • У вашего есть возможность переключать APPLIED_PRICE.

Этот способ (3*lwma-2*sma) объясняется в ссылке из поста (пожалуйста, проверьте ту ссылку тоже, эта ссылка https://www.mql5.com/ru/articles/270) и существует уже очень, очень давно и впервые был представлен на этом форуме (честно говоря, я не помню, кто именно впервые представил это algo, я думаю, что это был "mathemat", но, пожалуйста, не верьте мне на слово).

Что касается кода: код, который я выложил, является однопроходным (поэтому он и быстрый) и не имеет ничего общего с кодом Nikolays, который вы тоже можете проверить сами. Целью этого поста было опубликовать быстрый (с точки зрения процессора) способ, который является достаточно гибким для использования в любом типе кода. И, согласно всем тестам, он достаточно быстрый для использования в metatrader 5 и достаточно гибкий.

всего наилучшего

3 Methods of Indicators Acceleration by the Example of the Linear Regression
3 Methods of Indicators Acceleration by the Example of the Linear Regression
  • www.mql5.com
Fast calculation of the indicators is a vitally important task. Calculations can be accelerated by different methods. There are plenty of articles concerning this issue. And now we are going to examine 3 more methods to accelerate calculations and sometimes even to simplify a code itself. All described methods are algorithmic ones, i.e. we...
 
Mladen Rakic:


Что касается кода: код, который я выложил, является однопроходным (поэтому он быстрый) и не имеет ничего общего с кодом Nikolays, который вы тоже можете проверить сами. Целью этого поста было опубликовать быстрый (с точки зрения процессора) способ, который является достаточно гибким для использования в любом типе кода. И, согласно всем тестам, он достаточно быстрый для использования в metatrader 5 и достаточно гибкий.

ХОРОШО. Быстро - это хорошо. Я не сравнивал код, только результаты, поэтому я ошибочно сказал "та же математика".

Я использую код Nikolays уже некоторое время, и да, это самый медленный индикатор, который у меня есть. Быстрый - это хорошо.

Продолжайте в том же духе!

 
Automated-Trading:

Регрессия лайнера:

Автор: Младен Ракич

Отличная реализация. Поздравляю.

  • Какова цель этого? Обфускация? :-D
#define ¤ instance
#define _functionInstances 1
  • Есть ли какая-нибудь причина не использовать >= в приведенном ниже коде? ;-)
   if(i>period)
 
Alain Verleyen:

Отличная реализация. Поздравляем.

  • Какова цель этого? Обфускация? :-D
  • Есть ли какая-нибудь причина не использовать >= в приведенном ниже коде? ;-)

Никакой обфускации:

Из "¤": мне просто так больше нравится (это соглашение, которое я использую для себя - для меня код так более читабелен - один взгляд на код функции и я вижу, что именно где используется). Я мог бы использовать это непосредственно в качестве имени параметра, но тогда это было бы "слишком загадочно", когда я набираю имя функции и когда автозаполнение выводит имена параметров

Из "_functionInstances": поскольку он будет переведен в директиву времени компиляции, он служит для планирования - если я хочу использовать более одного экземпляра функции (т.е. разные параметры по какой-либо причине), то я просто меняю значение define, и тогда он компилируется в правильное число для распределения массива для использования с разными параметрами - и мне не нужно думать, изменил ли я его во всех местах кода, где это нужно сделать. И, будучи директивой времени компилятора, не требует затрат времени выполнения.

Что касается ">=" - две причины:

  • на одно условие меньше (которое выполняется при каждом вызове функции), если только компилятор не преобразует его во что-то другое (">="), но, судя по результатам профилирования, он использует это как 2 условия, а не 1 в этом случае
  • это нисколько не влияет на конечную скорость и позволяет убедиться, что все правильно настроено для дальнейшей обработки (одна дополнительная обработка начальных сумм позволяет убедиться в этом)
 
Mladen Rakic:

Никакой путаницы:

Из "¤": мне просто так больше нравится (это соглашение я использую для себя - для меня код так более читабелен - один взгляд на код функции и я вижу, что именно где используется). Я мог бы использовать это непосредственно в качестве имени параметра, но тогда это было бы "слишком загадочно", когда я набираю имя функции и когда автозаполнение выводит имена параметров

Из "_functionInstances": поскольку он будет переведен в директиву времени компиляции, он служит для планирования - если я хочу использовать более одного экземпляра функции (т.е. разные параметры по какой-либо причине), то я просто меняю значение define, и тогда он компилируется в правильное число для распределения массива для использования с разными параметрами - и мне не нужно думать, изменил ли я его во всех местах кода, где это нужно сделать. И, будучи директивой времени компилятора, не требует затрат во время выполнения.

Вам стоит попробовать ООП-подход.

Что касается ">=" - две причины:

  • одним условием меньше (которое выполняется при каждом вызове функции), если только компилятор не преобразует его во что-то другое (">="), но, судя по результатам профилирования, он использует это как 2 условия, а не 1 в этом случае.
Боюсь, я не понимаю, к чему вы клоните?
  • Это нисколько не вредит конечной скорости и позволяет убедиться, что все правильно настроено для дальнейшей обработки (одна дополнительная обработка начальных сумм позволяет убедиться в этом).

Конечно, ">" работает. Мое замечание было просто сказать, что вы теряете "1 цикл", конечно, это не сильно меняет конечную скорость. "Убедиться в этом" больше похоже на суеверие ;-)

 

Alain Verleyen:
You should try an OOP approach.

...

Вы имеете в виду что-то вроде этого :)

Это немного (но только немного) медленнее - я использую подход кольцевого буфера в режиме OOP, и это добавляет одну инструкцию мода ко всему вычислению, вот почему. Думаю, что и с постом все будет в порядке :)


 
Mladen Rakic:

Вы имеете в виду что-то вроде этого :)

Это немного (но только немного) медленнее - я использую подход кольцевого буфера в режиме ООП, и это добавляет одну инструкцию мода ко всему вычислению, вот почему. Думаю, что и с постом все будет в порядке :)


Да, это всегда компромисс между скоростью и памятью.

И, конечно, главное преимущество ООП - это обслуживание и возможность повторного использования, а не скорость.

 
Меня всегда интригует правильная математика. Модель линейной регрессии для (x,y) хорошо подходит для рынка. Я немного поэкспериментировал с NumPy, используя (bars,price,volume) (взвешивание по объему), получив похожие результаты. Также я делал взвешенную квантильную регрессию по объему, повторяя (time,price), сортируя и затем находя результаты. Легкая задача с NP, невозможная для меня на MQL5.
12
Новый комментарий