Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Новые ответы и новые вопросы - у вас все еще быстрее чем должно бы быть. И причина так же очевидна - сделок до сих пор меньше чем у меня (43012 при тех же настройках)... Хотя разница уже не так велика - порядка 10%.
Но вот что еще с этим делать - пока не придумал.
Изменения в таблицу внес.
Mathemat, прогони у себя тест при параметрах как у Петра в посте - сколько будет сделок?
Петр, это у тебя максимальное количество сделок? Ну то есть сортировка результатов по кол-ву сделок?
Петр, это у тебя максимальное количество сделок? Ну то есть сортировка результатов по кол-ву сделок?
Нет. Это просто первая итерация оптимизации. Тебя интересует экстремумы по кол-ву? Тогда мне надо будет заново тест запускать - вышел я уже из того терминала. Но могу - комп пока не загружен. Так нужно?
510 -12767.51 8719 0.72 -1.46 13779.51 1.38% MovingPeriod=55 MovingShift=10 Lots=0.1 MaximumRisk=0.02 DecreaseFactor=3
1 -56968.97 39923 0.61 -1.43 57046.37 5.70% MovingPeriod=5 MovingShift=1 Lots=0.1 MaximumRisk=0.02 DecreaseFactor=3
Ну вот, как ни странно, это были первая и последняя итерации.
Что я еще могу сделать? Могу выложить файл экспорта истории (22 метра архива - 150 несжатых) и ты прогонишь свой тест, импортнув ее. Спред у меня на момент оптимизации (я в офф-лайне гонял) был 17 пп. в их, алпаревском пятизнаке. Можешь тоже его выставить - ссылку на прогу я приводил.
Мой тест - так же, 9:05.
1 -56631.66 41959 0.62 -1.35 56711.86 5.67% MovingPeriod=5 MovingShift=1 Lots=0.1 MaximumRisk=0.02 DecreaseFactor=3
Похоже, Петр, что у тебя сортировка по числу сделок, т.к. внешние параметры у меня при такой сортировке те же, что у тебя (выделены голубым). Ну 5% мы скостили, но меня это не удовлетворяет...
Тут BARS посоветовал поставить внешнюю видяху (интегрированная отжирает память). Это я смогу проверить.
И, думаю, есть еще один фактор - синхронизация FSB камня и памяти. Максимум производительности - тогда, когда они равны, но мне пришлось бы разогнать камень в полтора раза, примерно до 3.8 GHz. Камень-то такое выдержит, он способен, но платка у меня не та, не для разгону...
А тайминги пямяти не сильно критичны, вроде где-то на ixbt читал.
P.S. У меня тоже Альпари, но данные я качал с метаквотовского сервака.
У меня общее количество сделок 6 710 383, и соответственно среднее за проход 13157.61
Тут BARS посоветовал поставить внешнюю видяху (интегрированная отжирает память). Это я смогу проверить.
И, думаю, есть еще один фактор - синхронизация FSB камня и памяти. Максимум производительности - тогда, когда они равны, но мне пришлось бы разогнать камень в полтора раза, примерно до 3.8 GHz. Камень-то такое выдержит, он способен, но платка у меня не та, не для разгону...
А тайминги пямяти не сильно критичны, вроде где-то на ixbt читал.
Интегрированным видео можно при такой скрости памяти и наличии 2 каналов пренебречь - серьезно тормозить будет только в 3D. А на десктопе в пределах погрешности измерений.
А для синхронности работы FSB процессора и памяти можно снизить коэффициент умножения. 7*400 например будет всего 2.8 ГГц.
Чувствительность к таймингам зависит в первую очередь от задачи. Некоторые программы вообще не замечают ухудшения таймингов, а некоторые реагируют весьма заметно.
Ну хорошо.
Раз мы хотим реалистичности в тестировании скорости работы тестера, и очень не хотим иметь дело с бестолковыми и не имеющими ни какого отношения к реальности неторгующими экспертами, а так же с бесполезными сферическими конями, прикинем, сколько времени на что тратится.
1. Накладные расходы работы терминала и оптимизатора в нём. t1
2. Время записи логов в файл. t2
3. Время исполнения эксперта, полный 1 цикл на баре void start(). t3
Общее время:
T=k*bars*(t1+t2+t3)
k-количество проходов в оптимизаторе, у всех одинаковое, const
bars - количество баров в истории, различие у участников тестирования не более 1%(надо полагать), можно принять с достаточной точностью, const
t1-от внешних факторов не зависит (погода на улице, экономический кризис и т.д. :), зависит только от тестируемого железа.
t2 - зависит от жд.
t3 - зависит от очень многих факторов, не связанных напрямую с железом, и влияющих на точность результатов из за содержания в коде торговых функций.
Для обеспечения равных условий для всех участников тестирования на какие из трех компонентов мы можем повлиять?
Ну, наверное, t3.
С количеством сделок что то поделать сложно. Но зато можно добавить в код эксперта блок "очень полезных" вычислений, с тем, чтобы снизить влияние негативных для тестирования факторов до минимума. Скажем, что бы блок "очень полезных" вычислений занимал 95-99% от всего времени. Всё. Задача решена. Будет достигнута достаточно высокая достоверность для наших опытов.
зы. На счет сферического коня ака скрипт. Существует очень много задач, не связанных с оптимизаций экспертов в оптимизаторе. Это и жадные до вычислительных ресурсов индикаторы, и сложные мат вычисления в скриптах. Например, у меня индикатор использует нс с нейронами 400-600-200. И того 360800 весов. Для тренировки этого тяжеловеса использую отдельный скрипт. А индикатор уже читает готовые веса из файла. Ясно, что если реализовать тренировку в самом индикаторе, будем иметь проблемы с отображением графика. Можно приводить примеры и дальше.
Ай, я тоже так хотел, кстати. У меня - 6 577 074 сделок, чуть меньше, чем у тебя, Docent.
P.S. Вот только что еще раз прогнал. Время - 8:18 (498 сек!!!), хотя ничего не делал абсолютно. Но того затыка (раньше "задумывалась" оптимизация на минутку где-то) теперь не было.
Нужные оба файла удалил (из кэша и истории). Ничего не понимаю. Ща еще попробую видяху поставить.