Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
У меня прямо противоположный опыт. ...
так бы сразу и сказали, что ваш противоположный опыт -- это отсутствующий опыт.
в таких случаях обычно на форуме и в личной перепиской интересуются, мол, как лучше и как правильно сделать.
а вы подаёте это всё как единственно верное и правильно решение -- которое таковым не является, к сожалению.
если в советнике используется время, как функция ограничения работы советника -- то при корректной её записи -- задание времени "-1" или "25" часов никак на работу советника не повлияют и буду растолкованы советником как "нет ограничения" по времени.
но при оптимизации часов шаг нужен, т.к. есть разница оптимизировать "каждый час", "каждые четыре часа" и т.п.
если задать:
при такой записи советник будет работать не корректно?
так бы сразу и сказали, что ваш противоположный опыт -- это отсутствующий опыт.
в таких случаях обычно на форуме и в личной перепиской интересуются, мол, как лучше и как правильно сделать.
а вы подаёте это всё как единственно верное и правильно решение -- которое таковым не является, к сожалению.
если в советнике используется время, как функция ограничения работы советника -- то при корректной её записи -- задание времени "-1" или "25" часов никак на работу советника не повлияют и буду растолкованы советником как "нет ограничения" по времени.
но при оптимизации часов шаг нужен, т.к. есть разница оптимизировать "каждый час", "каждые четыре часа" и т.п.
Что тут можно сказать? Автор волен на свой вкус писать код. Я, например, для времени использую enum и нахожу такой способ очень удобным. И вообще идеальный советник - это тот который не имеет входных параметров :) .
если задать:
при такой записи советник будет работать не корректно?
Да, выкинет сразу с ошибкой. Так как нет таких часов "-1" и "25".
А если пользователь введёт "125" при оптимизации? Это будет сотня лишних (или отброшенных) проходов. А если таких параметров несколько и в каждом ошибка? Тогда это сотня * сотня * сотня = вся оптимизация коту под хвост, так как в ней будут сплошные выбраковки.
А вот при enum такого априори не может быть. Будет максимум 24 прохода для часов.
Да, выкинет сразу с ошибкой. Так как нет таких часов "-1" и "25".
А если пользователь введёт "125" при оптимизации? Это будет сотня лишних (или отброшенных) проходов. А если таких параметров несколько и в каждом ошибка? Тогда это сотня * сотня * сотня = вся оптимизация коту под хвост, так как в ней будут сплошные выбраковки.
А вот при enum такого априори не может быть. Будет максимум 24 прохода для часов.
вы серьёзно всё это сейчас пишите?
в OnInit() нельзя убрать ошибочный выход за пределы?
обязательно надо пожертвовать шагом оптимизации.
я примерно прикинул, вы в кодабазе опубликовали 10% кодов.
есть такая немецкая пословица (специально поискал эквивалент известной русской, чтобы не придраться): "Слепое усердие только вредит".
Периодически советник открывает (при прогоне на истории) на всю свободную маржу несколько десятков одинаковых ордеров по одной цене, в итоге сливает. Чем это вызвано?
Периодически советник открывает (при прогоне на истории) на всю свободную маржу несколько десятков одинаковых ордеров по одной цене, в итоге сливает. Чем это вызвано?
Такова логика: если есть позиция и её прибыль более нуля и при этом можно открывать по времени - открывается ещё позиция в том-же направлении. Причём это может быть на каждом тике. Можно ограничить, если: