Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
просто интересно - а вы тут в качестве предикторов берете только значения цен и разных индикаторов от цен? а объемы реальные и индикаторы от объемов кто-нибудь использует?
Я с ценами работаю, без объёма.
Пробовал использовать объёмы и их индикаторы, но не получилось. Реальных объёмов на форексе не дано, зато есть тиковые, которые вроде чучуть соответсвуют реальным, т.е. в принципе их можно попробовать. Но проблема в том что история баров и тиков от брокера содержит какие-то "не такие" тиковые объёмы. Пока символ находится в маркет вотче в запущенном терминале - для него соответсвенно набирается правдивая история тиковых объёмов. Если символ убрать из вотча, или закрыть терминал - тиковые объёмы для таких баров будут браться те что даёт брокер. И вот эти два значения, "набранные самим терминалом" и "полученные от брокера" - совсем отличаются, иногда в десять раз. Теперь мне нужно держать терминал запущенным пару месяцев, чтоб набрать действительные тиковые объёмы, а не то что даёт брокер, тогда смогу ещё раз попробовать их использовать.
Я с ценами работаю, без объёма.
Пробовал использовать объёмы и их индикаторы, но не получилось. Реальных объёмов на форексе не дано, зато есть тиковые, которые вроде чучуть соответсвуют реальным, т.е. в принципе их можно попробовать. Но проблема в том что история баров и тиков от брокера содержит какие-то "не такие" тиковые объёмы. Пока символ находится в маркет вотче в запущенном терминале - для него соответсвенно набирается правдивая история тиковых объёмов. Если символ убрать из вотча, или закрыть терминал - тиковые объёмы для таких баров будут браться те что даёт брокер. И вот эти два значения, "набранные самим терминалом" и "полученные от брокера" - совсем отличаются, иногда в десять раз. Теперь мне нужно держать терминал запущенным пару месяцев, чтоб набрать действительные тиковые объёмы, а не то что даёт брокер, тогда смогу ещё раз попробовать их использовать.
Для информации по языку R и новому MetaTrader 5 build 1467:
Статистические распределения в MQL5 - берем лучшее из R и делаем быстрее
В ближайших версиях будет добавлена масса новых математических и статистических функций, аналогичных R. Это позволит больше расчетов и визуализаций вести прямо в MetaTrader 5.Обновиться до 1467 можно с сервера MetaQuotes-Demo.
Уважаемый Ренат!
Позвольте ответить на замечание по пункту №6. Обнаруженные ошибки расчетов в R по приведенной ссылке: Статистические распределения в MQL5 - берем лучшее из R и делаем быстрее
Проверка была выполнена для Гамма-функции. Для остальных функций оставляем проверку на вашу ответственность.
От лица отдела Data Science в лице руководителя и двух статистиков (команию могу сообщить в ЛС) информируем вас о том, что плотность гамма-распределения в точке ноль не сводится к нулю, строго говоря.
R действительно оценивает плотность в точке ноль как 1:
x <- seq(0, 20, 0.5) #support
plot(k, dgamma(x = x, shape = 1, scale = 1, log = FALSE)) #PDF plot
print(dgamma(x = 0.000001, shape = 1, scale = 1, log = FALSE)) #limiting to zero
Однако видно, что при x стремящимся к нулю плотность приближается к единице.
Более того, согласно:
https://en.wikipedia.org/wiki/Gamma_distribution
при x = 0, alpha = 1, beta = 1, в числителе получается неопределенное значение, что приводит всю дробь к неопределенности.
Заявляем, что строго говоря, плотность гамма распределения в точке ноль не определена. А при взятии предела справа плотность равна единице.
В свете этого мы считаем, то формулировка утверждения "ошибки расчетов в R" не является корректной. Точнее, это вопрос конвенций: чем считать равной выражение ноль в степени ноль. Приравнивание плотности гамма распределения к нулю в точке ноль не представляется сколько-либо обусловленной практикой.
С ув.
Алексей
Заявляем, что строго говоря, плотность гамма распределения в точке ноль не определена. А при взятии предела справа плотность равна единице.
В свете этого мы считаем, то формулировка утверждения "ошибки расчетов в R" не является корректной. Точнее, это вопрос конвенций: чем считать равной выражение ноль в степени ноль. Приравнивание плотности гамма распределения к нулю в точке ноль не представляется сколько-либо обусловленной практикой.
Если плотность (pdf) ненулевая, то и интеграл (cdf) в этой точке должен быть ненулевой, иначе нуля не получится.
Но cdf=0. Это трудно объяснить.
В точке x=0 pdf равна нулю по определению:
Wolfram Alpha:
Для нецентрального и центрального распределений хи-квадрат:
Если плотность (pdf) ненулевая, то и интеграл (cdf) в этой точке должен быть ненулевой, иначе нуля не получится.
Но cdf=0. Это трудно объяснить.
В точке x=0 pdf равна нулю по определению:
Wolfram Alpha:
Для нецентрального и центрального распределений хи-квадрат:
Вы лучше сами от себя скажите, чему равен 0 ^ alpha - 1, при alpha = 1.
Интеграл тоже там не определен.... Но в пределе близок к нулю. Вопрос конвенций...
print(pgamma(q = 0.000001, shape = 1, scale = 1, log = FALSE, lower.tail = F)) #right side
print(pgamma(q = 0.000001, shape = 1, scale = 1, log = FALSE, lower.tail = T)) #left side
а объемы реальные и индикаторы от объемов кто-нибудь использует?
чтобы предел был определен, нужно чтобы он был одинаковым при подходе слева и справа, но этого нет:
http://www.wolframalpha.com/input/?i=Limit%5BPDF%5BGammaDistribution%5B1,1%5D,x%5D,+x-%3E0%5D
чтобы предел был определен, нужно чтобы он был одинаковым при подходе слева и справа, но этого нет:
http://www.wolframalpha.com/input/?i=Limit%5BPDF%5BGammaDistribution%5B1,1%5D,x%5D,+x-%3E0%5D
Есть только справа и это 1...
То, что Wolfram говорит 0 - это не истина в последней инстанции. Я про то, что слово "ошибка" в формулировке излишнее...
Я ещё одну ошибку в R нашёл. R неправильно на 0 делит.
Вот скрипт:
//| test.mq5 |
//| Copyright 2016, MetaQuotes Software Corp. |
//| https://www.mql5.com |
//+------------------------------------------------------------------+
#property copyright "Copyright 2016, MetaQuotes Software Corp."
#property link "https://www.mql5.com"
#property version "1.00"
#property script_show_inputs
input double div = 0.0;
//+------------------------------------------------------------------+
//| Script program start function |
//+------------------------------------------------------------------+
void OnStart()
{
//---
Print(1.0/div);
}
//+------------------------------------------------------------------+
Правильный ответ, в mql -
zero divide in 'test.mq5' (20,13)
с остановкой скрипта
Неприавильный, в R:
> 1/0
Inf
с продолжением работы скрипта
Я это веду к тому же что и Алексей - поведение программ в неопределённых условиях может отличаться, и это не ошибка. Как архитектурой положено, такой результат и будет.
Ещё одно интересное наблюдение. Делить на ноль нельзя. И нельзя извлекать корень из отрицательных чисел. Я помню с универа что это всё можно, но сейчас не об этом, в простой математике оба действия нельзя.
Почему если в mql поделить на 0 то это ломает весь скрипт и обрывает его, а если извлечь корень из отрицательного числа - то получится число "-nan(ind)", без обрыва скрипта, и это "-nan(ind)" можно использовать дальше для вычислений (оно сломает все следующие вычисления)? Вот тут я ожидал одинакового поведения mql скрипта в обоих случаях.