Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Не пойдет, OnTester вызывается после прохода, а ТС надо во время.
Как хакнутый вариант, в OnTick проверять кол-во сделок и делить на ноль. Это для тестера, как и спрашивали. Или надо именно для оптимизатора?
Судя по первому посту, если я правильно понимаю контекст, речь, именно про критерий оптимизации.
По следующим постам уже похоже, что нужна преждевременная остановка.
Хакерство ни к чему хорошему не приведет, в таком случае лучше использовать: ExpertRemov() ;)
Но тем не менее, код с критерием может потребуется кому-то другому - тому, кто умеет пользоваться поиском :)
Судя по первому посту, если я правильно понимаю контекст, речь, именно про критерий оптимизации.
По следующим постам уже похоже, что нужна преждевременная остановка.
Хакерство ни к чему хорошему не приведет, в таком случае лучше использовать: ExpertRemov() ;)
Но тем не менее, код с критерием может потребуется кому-то другому - тому, кто умеет пользоваться поиском :)
Ему нужно так, чтобы при оптимизации оптимизатор не гонял прогон, если в нём меньше сделок, чем некое их подходящее количество. Т.е., изначально перепутаны причины и следствия. Я говорил уже, что сиё сделать невозможно - ведь пока оптимизатор не прогонит очередной тест, он не узнает сколько в этом прогоне было сделок, и не перейдёт к следующему если в этом сделок мало.
Не хочет понять...
Как я понял топикстартера, ему нужно вот что:
1. Оптимизатор увидел, что в текущем прогоне мало сделок и остановил этот прогон, и перешёл к следующему, отбросив в урну результаты остановленного прогона.
2. В следующем прогоне оптимизатор делает то же самое, что и в предыдущем - видит мало сделок, останавливает пргон, его результаты в урну, и идёт дальше - на следующий.
3. В результате после прохода всей оптимизации результат оной должен содержать лишь те прогоны, которые оптимизатор не забраковал.
Т.е., в итоге - ноль прогонов. Так как 1 сделка - уже мало. Значит прогон выкидываем, ну и т.д. ...
Мне бы пригодилась аналогичная фича - не показывать результаты с просадкой превышающей заданную.
Ему нужно так, чтобы при оптимизации оптимизатор не гонял прогон, если в нём меньше сделок, чем некое их подходящее количество. Т.е., изначально перепутаны причины и следствия. Я говорил уже, что сиё сделать невозможно - ведь пока оптимизатор не прогонит очередной тест, он не узнает сколько в этом прогоне было сделок, и не перейдёт к следующему если в этом сделок мало.
Не хочет понять...
Как я понял топикстартера, ему нужно вот что:
1. Оптимизатор увидел, что в текущем прогоне мало сделок и остановил этот прогон, и перешёл к следующему, отбросив в урну результаты остановленного прогона.
2. В следующем прогоне оптимизатор делает то же самое, что и в предыдущем - видит мало сделок, останавливает пргон, его результаты в урну, и идёт дальше - на следующий.
3. В результате после прохода всей оптимизации результат оной должен содержать лишь те прогоны, которые оптимизатор не забраковал.
Т.е., в итоге - ноль прогонов. Так как 1 сделка - уже мало. Значит прогон выкидываем, ну и т.д. ...
Да уж, эту тему мне просто надо было читать снизу вверх, как ни странно :)
Мне бы пригодилась аналогичная фича - не показывать результаты с просадкой превышающей заданную.
Вот для таких целей преждевременная остановка, действительно, имеет смысл.
Но ключевым моментов, все равно, остается функция: ExpertRemove() (который вызываем по условию в любой момент, например, как посоветовал BlackTomcat) и часть кода, который я привел (даже при принудительной остановке при помощи ExpertRemove, все равно сработает OnTester), иначе (если не использовать "Custom max") в результатах прогона можем получать не те цифры, которые хотелось бы...