Новая версия платформы MetaTrader 5 build 6230: больше возможностей AI - страница 14
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
B6230. Дилер Финам, инструмент chmf.
Баланс считается не по прибыли, а неизвестно по чем:
первая сделка должна прибавить +21, но вычла 1021.8.
вторая должна вычесть 4.60, но прибавила 28.8
Комиссии, сборы, свопы = 0, что видно на скриншоте.
Ошибка или какие то скрытые платежи и бонусы?
Эксперт MA из примеров с настройками по умолчанию. Та же проблема.
С доступом к счету можно проверить и эту ошибку с расчетом баланса.
Решил распечатать тики в более наглядном виде, чем выше и обнаружил баг.
Код для воспроизведения:
Несколько строк из терминала:
Они же из распечатки:
2024.06.07 18:49:14 2024.06.07 18:49:14.928 122.5 122.5 122.5 10 10.0 344
2024.06.07 18:49:38 2024.06.07 18:49:38.883 122.5 122.5 122.5 1 1.0 344
2024.06.07 18:49:55 2024.06.07 18:49:55.460 122.5 122.5 122.5 14 14.0 344
2024.06.07 19:00:04 2024.06.07 19:00:04.717 123.0 134.12 122.5 14 14.0 6
2024.06.07 19:00:05 2024.06.07 19:00:05.252 123.0 122.96 122.5 14 14.0 4
2024.06.07 19:00:05 2024.06.07 19:00:05.604 123.0 122.58 122.5 14 14.0 4
2024.06.07 19:00:06 2024.06.07 19:00:06.885 123.01 122.58 122.5 14 14.0 2
2024.06.07 19:00:13 2024.06.07 19:00:13.358 131.13 122.58 122.5 14 14.0 2
2024.06.07 19:00:13 2024.06.07 19:00:13.876 131.13 122.5 122.5 14 14.0 4
2024.06.07 19:00:54 2024.06.07 19:00:54.961 132.5 122.5 122.5 14 14.0 2
2024.06.07 19:01:30 2024.06.07 19:01:30.77 131.13 122.5 122.5 14 14.0 6
2024.06.07 19:01:31 2024.06.07 19:01:31.830 132.5 122.5 122.5 14 14.0 2
2024.06.07 19:01:42 2024.06.07 19:01:42.297 131.13 122.5 122.5 14 14.0 2
2024.06.07 19:01:45 2024.06.07 19:01:45.138 134.0 122.5 122.5 14 14.0 2
2024.06.07 19:03:19 2024.06.07 19:03:19.156 134.0 122.49 122.5 14 14.0 6
2024.06.07 19:03:20 2024.06.07 19:03:20.834 134.14 122.49 122.5 14 14.0 2
2024.06.07 19:03:32 2024.06.07 19:03:32.904 134.0 122.49 122.5 14 14.0 2
2024.06.07 19:03:38 2024.06.07 19:03:38.211 131.13 122.49 122.5 14 14.0 2
2024.06.07 19:03:46 2024.06.07 19:03:46.854 134.0 122.49 122.5 14 14.0 2
2024.06.07 19:04:06 2024.06.07 19:04:06.388 134.0 122.48 122.5 14 14.0 6
2024.06.07 19:04:47 2024.06.07 19:04:47.817 134.0 122.4 122.5 14 14.0 4
2024.06.07 19:04:52 2024.06.07 19:04:52.26 134.0 122.4 122.55 20 20.0 344
2024.06.07 19:04:52 2024.06.07 19:04:52.26 134.0 122.4 122.55 5 5.0 344
Выделенные строки показывают объем 14, но объем не указан на скриншоте из терминала, т.е. = 0.
Предполагаю, что тестер не отфильтровал их по флагам и оставил последний объем из известных, так же и цену Last оставил последнюю 122.5.
Только не пишите, что я должен костылить правильные объемы и Last-ы через флаги. Инструкция https://www.mql5.com/ru/docs/constants/structures/mqltick этого не предлагает.
Какая то деградация платформы (. Примитивные, базовые вещи ломают.
И это можно проверить. Ask/Bid тики показывают объем !=0 (от последнего Last тика). Так как в примере из документации https://www.mql5.com/ru/docs/constants/structures/mqltick не показано, что объем нужно получать после проверки флага, то можно сделать вывод, что тестер и терминал должны сами обнулять его. Но этого сейчас не происходит и нужно исправить.
Если не согласны - то нужно менять документацию и показать правильное получение объема.
Протестировал еще ситуацию с тиками в неторговое время.
1) открыл сделку sell в торговое время в 18:39:59 со стопом ниже цен которые были в неторговое (видно по тонкой красной линии, где была Ask). И что интересно стоп не сработал. Это обнадеживает. Но не понятно, как тестер определил, что время неторговое и что нельзя применять SL.
2) отправил запрос на sell в неторговое время в 18:49:55 и тестер его исполнил, но биржа должна отклонить. Это однозначно ошибка и если бы был флаг, как предлагаю, то и это можно было бы отклонить.
Предполагаю, что тестер определяет неторговое время по отношению цен Bid Ask и поэтому не исполнил SL.
Из экспорта тиков:
В 18:40:02 ставится неправильные Bid>Ask потом идут тики без объемов и с 18:45 тики с объемами.
В 19:00:04.717 123.00 134.12 всего 1 тик ставится правильным Bid<Ask, но Ask ставится очень большим (красная линия на графике)
В 19:00:05 снова неправильные Bid>Ask, дальше тики без объемов и с объемами
В 19:04:52 возвращается правильный Bid<Ask и дальше с 19:05 начинается торговая сессия.
Получается что при Bid>Ask неторговое время и нужно все пропускать.
Но тик в 19:00:04 не укладывается в это предположение. Возможно дополнительным фильтром является то, что он без объема, т.е. до первого тика с объемом после Bid>Ask нужно все тики пропускать.
Видимо это и есть хитрый костыль которым пользуется MQ тестер и биржа. А можно было бы просто 1-м битом из флагов.
Но ошибку из п.2 это не предотвратило.
Попробую и себе это закодировать.
Прореженый экспорт тиков (удалены сотни тиков с объемами), если кому интересно:
Это тоже можно проверить предложенным выше экспертом.
Файл с настройками no_trade.set
Отправляем торговый запрос во время когда открылась котировочная сессия (с 6:50), но еще не открылась торговая сессия. Биржа это отклонит. Тестер торгует, но не должен.
Поэтому есть предложение добавить новый флаг который указывает к какой сессии относится тик: торговая или котировочная. Тогда будет очень просто отклонять ордеры в неторговое время.
Найденная закономерность с использованием Bid>Ask в начале не торговой сессии не очень четко работает, как видно на этом примере. Решение с флагом будет давать 100% разделение сессий.
Если MQ его сделает, то можно будет сделать скрипт, которым можно быстро установить флаги в истории на серверах бирж. Ведь только они четко знают график сессий.
Например по акции Gazp
- не торговая сессия начиналась в 9:50, торговая в 10:00
- с 2025 стало 6:50 и 7:00
- менеджер сказал, что скоро будут еще изменения
Спецификация инструмента может показывать только текущую ситуацию с сессиями, но не её изменения в прошлом. Видимо поэтому вообще установили круглосуточную торговую сессию.
Биржа показывает такое
С флагом определение торговой сессии будет работать идеально.
Выделенные строки показывают объем 14, но объем не указан на скриншоте из терминала, т.е. = 0.
Это неверная интерпретация пустого поля. Например, когда в Ask пусто.
То есть для Ask и/или Bid тиков без флага Volume надо оставить объем=14 от последнего Last? По распечатке видно, что именно он там остается на протяжении нескольких тиков.
Тогда в документации надо привести правильный пример получения объемов через использование флагов.
Последними надо осталять только цены Ask и Bid. Остальное по фактическому значению, т.е. по флагам.
Думаю сейчас немало экспертов работает, которые так же просто, как в примере получают объем (VSA и т.п.). И если идет его суммирование, то получается завышение от объемов из Ask/Bid тиков. Т.е. получается неадекватное тестирование. А из него только такой же результат можно выбрать для установки на реальную торговлю с повышенным риском потерь.
Да и изначально речь шла про объем, а не Ask столбец.
То есть для Ask и/или Bid тиков без флага Volume надо оставить объем=14 от последнего Last? По распечатке видно, что именно он там остается на протяжении нескольких тиков.
SymbolInfoTick содержит в своих MqlTick-полях последние пришедшие значения. И только flags говорит, что менялось.
Вы предлагаете это условие изменить для Last/Volume-полей, заменяя их значения нулями.
Но какой смысл в этом? Помимо потери информации о прошлом мы ничего не выигрываем. Т.к. проверка на нулевой объем и проверка на флаг объема - почти одно и то же.
Но какой смысл в этом? Помимо потери информации о прошлом мы ничего не выигрываем. Т.к. проверка на нулевой объем и проверка на флаг объема - почти одно и то же.
Не проверка, а использование объема, которое на самом деле = 0, так как флаг объема не установлен.
Вы предлагаете это условие изменить для Last/Volume-полей, заменяя их значения нулями.
Да - привести в соответствие флагам, а не оставлять там данные от последнего Last
так же просто, как в примере получают объем (VSA и т.п.). И если идет его суммирование, то получается завышение от объемов из Ask/Bid тиков.
Я не в курсе, про какой пример идет речь. Но это работало бы корректно только в случае, если объем мог быть отрицательным для SELL-сделок и положительным - для BUY.
Тогда, действительно, можно было бы писать вот так удобно и быстро по вычислениям.
Но в MQ решили, что объемы только положительные. Поэтому прибавлять или отнимать возможно только по анализу flags.
Но в MQ решили, что объемы только положительные. Поэтому прибавлять или отнимать возможно только по анализу flags.
Так пример то без анализа флагов сделан. Получили объем и делай с ним что хочешь, например суммируй.
До этого я никогда не проверял флаги получая объем. В соответствии со справкой. И теперь увидел, что это ошибка и результаты сумм завышены. Сколько людей перепроверяли истинность примеро в из документации? Все принимают их за истину.
Еще раз - меня смущают наличие объемов в Ask/Bid тиках без флага Volume, а не buy/sell тиков.Да - привести в соответствие флагам, а не оставлять там данные от последнего Last
Получается, что одно правило для Bid/Ask и другое - для Last/Volume.
Тут надо всесторонне смотреть. Потому что же еще есть и CopyTicks-данные. Как они расходятся с SymbolInfoTick, не знаю/помню.