Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Ты прав.
Поучительно здесь следующее - при попытке открыть Бай-позицию, используется значение предопределённой переменной Ask.
Эксперт "запоминает" её значение в момент запуска (начало ф-ции start()). Поэтому если с этого времени прошла секунда (следовательно, Аск мог поменяться), необходимо "освежить" данные.
Этим и занимается ф-ция RefreshRates() =)
У меня это работает корректно, т.к. проверка осуществляется по приходу каждого тикета, а не после if (prevtime = Time[0]) return(0);
Я смотрел по журналу, как это может быть и выявил, что такое случается, когда связь с интернет прерывается по каким либо причинам.
Эксперт отдает приказ открыть позицию. Коннект рвется и эксперт получает ошибку. Потом, коннект восстанавливается, эксперт смотрит в историю счета и не найдя там открытой позиции опять отдает приказ. В это время приходит подтверждение о том, что позиция по первому приказу открыта. Следом открывается вторая позиция.
В принципе это можно вылечить, если задать большую задержку на восстановление связи с провайдером после обрывов. Но не всегда поможет, т.к. может разорваться и TCP/IP коннект, без обрыва модемной связи, например, если где по пути маршрутизатор заклинил. Пока новый маршрут проложится, советник нахватает багов.
Такое происходит очень редко, но жутко неприятно. Поэтому я предпочитаю все приказы на открытие позиций отдавать только после того, как предыдущий бар сформировался.
Да и внутрибаровый технический анализ, если таймфрейм M30 или более тоже может выдавать неприятности. Индикаторы дрыгаются как кое-что неприличное в кое-чем неприличном. И получается, что эксперт в одном периоде (баре) получает сигнал открыть позицию, потом закрыть и так многократно. Результат - несколько непрерывных убытков на спрэдах.
Чего мудрить над каждым тикетом, когда выясняется, что советники прошедшие успешно все тесты, начинают гнать пургу уже на демодепозитах. Только время зря терять на всякие ухищрения. А ради чего спрашивается?
Это из справки =)
Поучительно здесь следующее - при попытке открыть Бай-позицию, используется значение предопределённой переменной Ask.
Эксперт "запоминает" её значение в момент запуска (начало ф-ции start()). Поэтому если с этого времени прошла секунда (следовательно, Аск мог поменяться), необходимо "освежить" данные.
Этим и занимается ф-ция RefreshRates() =)
Спасибо за информацию.
Только сейчас обнаружил Ваш ответ внутри моей старой записи (сливается).
С этим сталкивается эксперт. Он просто игнорирует тех, кто опоздал. Что по сути правильно. Ведь разные тики по TCP/IP протоколу могут прийти на клиентский терминал не обязательно в том порядке, каком они были отправлены сервером.
Что-то мне не верится, что Bid и Ask могут приходить в беспорядочном порядке. Но если это так, то все программы основаные на тиках фалят время от времени.
Ты хорошо подумал прежде чем так ответить? Речь шла о том, что разные тикеты могут прийти на терминал в неправильном порядке или даже быть проигнорированы терминалом. Ask и Bid приходят в одном тикете. Т.е. если терминал получил тикет, то значит он получил и аск, бид и уникальный идентификатор этого самого тикета.
Что-то мне не верится, что Bid и Ask могут приходить в беспорядочном порядке. Но если это так, то все программы основаные на тиках фалят время от времени.
Ты хорошо подумал прежде чем так ответить? Речь шла о том, что разные тикеты могут прийти на терминал в неправильном порядке или даже быть проигнорированы терминалом. Ask и Bid приходят в одном тикете. Т.е. если терминал получил тикет, то значит он получил и аск, бид и уникальный идентификатор этого самого тикета.
Хотя это зависит от величины этой беспорядочности.
Что-то мне не верится, что Bid и Ask могут приходить в беспорядочном порядке. Но если это так, то все программы основаные на тиках фалят время от времени.
Ты хорошо подумал прежде чем так ответить? Речь шла о том, что разные тикеты могут прийти на терминал в неправильном порядке или даже быть проигнорированы терминалом. Ask и Bid приходят в одном тикете. Т.е. если терминал получил тикет, то значит он получил и аск, бид и уникальный идентификатор этого самого тикета.
Хотя это зависит от величины этой беспорядочности.
Еще раз повторю, что индикаторы многократно меняют свои показания внутри бара. У меня сейчас МТС с полосами болинжера, дык там четко видно, что если цена идет вверх, то при каждом новом тикете верхняя граница болинжера то оказывается выше текущего Bid, то ниже. При движении вниз, такое же поведение наблюдается у нижней границы индюка. Т.е. торговые сигналы все время меняют свои показания на прямо противоположные в диапазоне не превышающим двойной спрэд.