Обсуждение статьи "Статистические распределения в MQL5 - берем лучшее из R и делаем быстрее" - страница 7
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
я хоть и говорю о R, однако мой скилл вери смолл)) кто-то может проверить правильность кода?
если код верен, то можете проверить бенчмарк?
Код ошибочен.
Вы же замерили время компиляции функции, а не ее исполнение:
The function cmpfun compiles the body of a closure and returns a new closure with the same formals and the body replaced by the compiled body expression.
Доказательство ошибочности:
Если бы во время бенчмарка запускалась функция qqq, то объект a получил бы расчитанные данные. Но вместо этого оказалось, что объект даже не был создан.
В результате бенчмарк посчитал время компиляции, а не время исполнения. В моем коде все верно - бенчмарк считает фактическое время исполнения и объект a создается с правильными данными.
И да, компиляция - достаточно затратный процесс: он в миллисекундах показан вместо микросекунд
Ну и отдельный прикол, как вы в своем примере переопределили системную функцию q() - quit.
Выйти из R нельзя было никак :)
Я к тому что mql компилятор во время компиляции уже знает все входные параметры. Ему достаточно во время компиляции всё посчитать, а при вызове скрипта - он просто возвращает уже заранее посчитанный результат. Видел какие-то статьи на хабре где сравнивали компиляторы на c++, там судя по анализу ассемблерного кода именно так происходит.
Да, может и активно этим пользуется. Вот примеры: https://www.mql5.com/ru/forum/58241
Но в данном случае это не пройдет - считать надо в полный рост из-за сложности, цикла и заполнения массива.
если код верен, то можете проверить бенчмарк?
Нужно res <- microbenchmark(cmpfun(q)) заменить на res <- microbenchmark(q()). Но уже ранее скомпилированные библиотеки в байткод не перекомпилятся, у меня резульаты остались теже.
"a" в таком случае будет локальной переменной, недоступной за пределами самой функции в любом случае. Но можно сделать так -
a <<- dbinom(k, n, pi/10, log = TRUE)
тогда она будет таки глобальной
Но в данном случае это не пройдет - считать надо в полный рост из-за сложности, цикла и заполнения массива.
понятно, скорость выполнения отличная тогда
Кстати, интерпретировать примитивный вызов a <- dbinom(k, n, pi/10, log = TRUE) с прямым проваливанием в ядро R с нативным исполнением (dbinom находится в r.dll) практически не стоит ничего.
Так что попытки скомпилировать этот вызов заведомо бесполезны.
Так как я много раз писал о быстродействии R, то позвольте вставить свои пять копеек.
Уважаемый Ренат!
Ваш пример вообще не о чем!
Вы взяли две аналогичные функции и делаете вывод вообще о быстродействии R.
Функции, которые Вы привели, вообще не отображают мощь и многообразие R.
Сравнивать надо вычислительно емкие операции.
Например, перемножение матриц...
Давайте померяем выражение на R
с <- a*b,
где a и b матрицы размером хотя бы 100*100. При этом Вы в своем коде проследите, чтобы R использовал MKL Intel. А это достигается просто установкой соответствующей версии R.
Если мы посмотрим на R, то горы кода, содержащего вычислительно емкие операции. Для их исполнения используются библиотеки, которые на данный момент максимальную эффективность.
И полезность Rв трейдинге не в функциях,которые Вы переписали (хотя они также необходимы), а в моделях. В одном из ответов Вам я упоминал пакет caret. Посмотрите, что это такое.... Вот реализация какой-либо практически полезной торговой модели в рамках этого пакета и на мкл и даст ответ
Кроме этого следует не забывать, что загрузка всех ядер компа - это рутина для R. Кроме этого можно загрузить соседние компы в локальной сети.
ПС.
Для меня является сомнительной идея сравнения быстродействия МКЛ и R: эти две системы имеют совершенно разные предметные области
СанСаныч, все проверим и выпустим бенчмарк. Но сначала допишем функционал.
Тест был обоснован и он сразу вскрыл проблему. Теоретическое обоснование я представил и уверен, что системный оверхед у R сохранится по подавляющему объему функционала.
Матрицы и мы перемножить можем так, что и Интел проиграет. Это давно уже не rocket science, а Интел(вернее, такие же сторонние программисты в рамках принадлежности к компании) не чемпион в мифическом знании своих процессоров.
Так как я много раз писал о быстродействии R, то позвольте вставить свои пять копеек.
.................
Сан-Санычу и другим ребятам.
Сан-Саныч, Вы же знаете как я Вас уважаю ... ((С) Катаев и Файнзильберг, известные как "Ильф и Петров"), несмотря на некоторые Ваши пост-советские приколы тут.
Позвольте я Вам поясню кое-что важное:
1). Основная работа программиста - это не писать программы, а ЧИТАТЬ программы, в частности свою. Любой программист 95...99% своего времени сидит и пялится в монитор. Разве он ПИШЕТ программу? Нет, он её в основном ЧИТАЕТ. Поэтому чем ближе к естественному языку будет то, что он читает на экране, то есть к тому, чему его учили мама, папа, бабушка, учительница в школе, - тем эффективнее он будет расшифровывать эти языко-пободные кракозябры на экране и втыкать соответствие между алгоритмом и своей программой.
2). Для целей пункта (1) нет ничего лучше в среднем, чем язык Си. именно поэтому, например мне лично (а также 2-3 ответственных, и не очень, человека) удалось написать проект объёмом в 700+ подпрограмм, на Си, MQL4, CUDA.... И всё работает.
3). С точки зрения пункта (1) объектно-ориентированный вариант Си, то есть Си++ намного хуже. (Но об этом в другой раз).
4). Полная совместимость классического Си и MQL4 просто бесценна. Перенос процедуры туда-обратно занимает полминуты.
5). Основное достоинство Си+MQL4 - это CLARITY. То есть понятность и прозрачность всего, что есть на экране у программиста.
Если сравнить Си-MQL4 с этой Вашей R, то здесь надо смотреть не на скорость и объём понаписанного кода, а на CLARITY текста. То есть на его понятность. Иначе программист будет сутками пялиться на экран, в тщетных попытках понять, что делает прога, какие у неё там параметры, почему автор их так назвал, и вообще почему программер сделал именно так, а не иначе. Тут не скорость программы важна, а правильность её работы, и скорость ЕЁ ПРИМЕНИМОСТИ у конечного программиста.
С этой точки зрения то, что сделали Метаквоты - конечно огромная поддержка тем, кто захочет вставить статистику в свои советники. Тут даже нечего сравнивать по степени простоты и понятности функций. А это важно. Особенно если у Вас тонкие расчёты (а Форекс и трейдинг вообще требует тонких расчётов).
Давайте сравним.
Вот как выглядит на Си - MQL4 функция интегрирования:
Буду писать частями, так легче писать.
Там есть внутри функция интегрирования трапецией:
Всё абсолютно ясно и понятно. И что важно, это работает всегда и работает хорошо, то есть с низкой погрешностью даже в MT4-MQL4, что экономит кучу времени.
Но если Вы захотите узнать почему у Вас вылазят непонятные погрешности при работе в R, или если Вы просто захотите разобраться какие там параметры в процедуре интегрирования или какой именно метод интегрирования они там запрограммировали, то Вы увидите следующее (прости Господи меня за выкладывание такого - незрелым отрокам программирования):
http://www.netlib.org/quadpack/
Это только заголовок функции, изначально написанной на Фортране. Основной текст будет позже. Это оригинал программы, которая используется в пакете R для интегрирования.
Что здесь можно понять, скажите мне?