Проблема: тестирование исключает последний день - страница 3
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
gip:
А при чем тут тики? Тики тут совершенно не при чем. Есть M1 M5 M10 M15 и т.д.
С тестером вообще непонятная ситуация. Он действительно какой-то оторванный от реальности получился.
Вычислительные фермы кому-то может и нужны, но думаю основной массе не понадобятся. Да и не в ту сторону движение, лучше бы в сторону оптимизации скорости выполнения торгового алгоритма. Для примера у меня полный многолетний тест выполняется за 7-8 секунд, не в МТ тестере конечно. И понятно что фермы тут совершенно не у дел.
А вот отладки в тестере да и вообще сегодняшнего дня нет.
Для тестирования самой стратегии полного кода эксперта вовсе и не требуется. Это к вопросу что отлаживать нужно эксперт, а оптимизировать стратегию. А мы оптимизируем эксперт, а не стратегию, и не можем его отлаживать. Всё задом-наперед.
Можете опять забросать меня кирпичами, но я совершенно не вижу в нем для себя пользы. Совершенно никакой.
Я так понимаю, что тестер своё последнее слово ещё не сказал. Он сейчас имеет только основной минимально необходимый функционал для подготовки к чемпионату. Основное внимание до сих пор уделялось торговому функционалу, стабильности, выявлению багов и недочетов в языке MQL5.
Но справедливости для стоит отметить на сегодняшний день не выигрышную по сравнению с четверочным тестером скорость работы, хотя и реализована многопоточность при оптимизации. Надеюсь, это пока временные болячки тестера. Насчет неудобного интерфейса я подал заявку в сервисдеск, она не закрыта до сих пор, это даёт основание думать, что разработчики ещё будут работать над юзабилити тестера.
Последнее время всё больше думаю над возможностью реализации самодельного тестера с применением CUDA. Выигрыш в скорости оптимизации, особенно крупных проектов с ANN, по сравнению с вычислениями на CPU должен быть колоссальным. Я ничего не имею против агентов, которые позволяют оптимизировать на многих тысячах компьютерах. Но хочется ещё и своего настольного суперкомпьютера, пусть он и уступит тем самым тысячам агентам. Можно сделать отдельный модуль на dll, и подключать его включаемым файлом в эксперты. В свободное время занимаюсь изучением CUDA, и, возможно, через год или два, сделаю тестер на этой технологии. Хотя, скорее всего, подобные решения появятся на рынке намного раньше. Ведь раз появился такой мощный язык программирования АТС, то должны появится и программные решения, позволяющие комфортно тестировать и оптимизировать могучие АТС.
Для тестирования самой стратегии полного кода эксперта вовсе и не требуется. Это к вопросу что отлаживать нужно эксперт, а оптимизировать стратегию. А мы оптимизируем эксперт, а не стратегию, и не можем его отлаживать. Всё задом-наперед.
Можете опять забросать меня кирпичами, но я совершенно не вижу в нем для себя пользы. Совершенно никакой.
Понял. Речь идёт об экспертах, не работающих на тиках.
Даже если принимать во внимание, что сгенерированные тики отличны от реальных, их наличие дает гораздо большие шансы на отладку и выявление проблем в ближайшем прошлом, чем закрытая на корню такая возможность (шансов ноль).
На самом деле, тестирование на реальных тиках тоже возможно, и это сняло бы вопрос с генерацией вообще. Ничего сложного в реализации нет - было бы желание. Сами тики, пришедшие на клиент, не являются секретом. Фактически уже сейчас имеются скрипты, которые тики сохраняют во внешних файлах, и апологеты тикового анализа потом их изучают со всех сторон. Размер данных не является сейчас критическим, особенно если можно было бы явно указывать, какой период тестирования меня интересует (а не так как сейчас - скачивается вся история сервера с 2000 года, даже если нафик не надо так далеко). Например, пользователь указывает терминалу, что нужно сохранять тики таких-то инструментов, и размер этого кеша не должен превышать 10 гиг на диске, или скажем нескольких месяцев истории. Далее во время тестирования тики берутся из кеша. Тестировать можно с точностью до последнего закешированного тика. И всякие проблемы с качеством генерации будут исчерпаны. Кому нужна генерация, мог бы опционально включать либо генерацию, либо кеширование. Даже редактирование кеша с помощью текущего протокола можно предусмотреть, и хранить версии одного и того же тика, например, до возникновения шпильки и после её удаления на сервере.
Извиняйте, я ж не знаю внутренней кухни и может быть сохранение тиков противоречит какой-то политике или религиозным соображениям - тогда обсуждать нечего. Это лишь поле деятельности для сторонних разработчиков. Лично у меня особых претензий к качеству искусственных тиков нет, достаточно их наличия.
Последнее время всё больше думаю над возможностью реализации самодельного тестера с применением CUDA. Выигрыш в скорости оптимизации, особенно крупных проектов с ANN, по сравнению с вычислениями на CPU должен быть колоссальным. Я ничего не имею против агентов, которые позволяют оптимизировать на многих тысячах компьютерах. Но хочется ещё и своего настольного суперкомпьютера, пусть он и уступит тем самым тысячам агентам. Можно сделать отдельный модуль на dll, и подключать его включаемым файлом в эксперты. В свободное время занимаюсь изучением CUDA, и, возможно, через год или два, сделаю тестер на этой технологии.
Пишите индикатор или скрипт, в котором не будет никаких проверок и воспроизведения рыночного окружения - тупой подсчет пунктов. Многие идут по этому упрощенному пути.
Да, кстати, это и самый простой но эффективный способ построения своего тестера. Подобные решения в свободном доступе имеются на сайте MQL4 в статьях и в CodeBase.
Боюсь, что потеряете время. Попробуйте сначала понять саму технологию, используемую в CUDA, может это остановит.
Понять уже попробовал. Затея представляется вполне реализуемой. На сайте CUDA масса примеров с исходными кодами, в том числе и с ANN и GA, можно использовать как отправную точку для разработки.
Пишите индикатор или скрипт, в котором не будет никаких проверок и воспроизведения рыночного окружения - тупой подсчет пунктов. Многие идут по этому упрощенному пути.
Пишите индикатор или скрипт, в котором не будет никаких проверок и воспроизведения рыночного окружения - тупой подсчет пунктов. Многие идут по этому упрощенному пути.
категорически возражаю против слова тупой.
https://www.mql5.com/ru/forum/106481
KimIV 10.01.2008 09:56
Рекомендую свою функцию. Общий срок разработки этой функции - более двух лет. Так что она проверена на многочисленных демо-счетах и само собой на реальных.
З.Ы. 2 года, вы хоть представляете, через что прошел трейдер, за это время, сколько он потратил времени, сил, нервов, денег прежде чем смог написать такую функцию.
З.З.Ы. Спроите себя, чем Вы именно Вы помогли ему ? тестером ? качеством исполнения сделок ? надежностью работай терминала ?
З.Ы. 2 года, вы хоть представляете, через что прошел трейдер, за это время, сколько он потратил времени, сил, нервов, денег прежде чем смог написать такую функцию.
Вы это говорите тем, кто пишет _миллионы_ строк кода (в противовес 50 строкам конкретной функции).