Ошибки, баги, вопросы - страница 3720
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
DEAL_PRICE для SL в режиме 1OHLC совпадает строго с ценой SL
Потому что альтернативного варианта в этом режиме быть не может даже теоретически.
Не могу понять почему в 1OHLC режиме нельзя закрывать позу также по цене Bid, как делают это режимы "Every tick" и "Every tick based on real ticks".
На тике закрытия во всех трех режимах ask/bid одинаковый, но в качестве DEAL_OUT_PRICE тестер применяет разные цены в разных режимах. Не могу понять зачем разный расчет делать в разных режимах, если можно одинаковую логику использовать.
Для уточнения еще 3 картинки (может я как-то непонятно объяснил).
(может я как-то непонятно объяснил).
Всё понятно объяснил.
fxsaber тоже всё понятно объяснил.
Попробую и я, другими словами. Немного утрированно.
При тесте по всем тикам тестер знает, что бар заполнен тиками и при гэпе выбирает для закрытия ближайший тик.
При торговле OHLC тестер знает, что бар заполнен тиками, но выбрать ближайший он не может, так как нет у него выбора (тиков нет), поэтому закрывает по указанной цене SL.
Думаю, при торговле по OHLC для гэпов в тестере было бы хорошо, чтоб разработчики сделали исключение и SL закрывать по ближайшей цене.
Предположительно ошибка появилась после обновления 5640.
Ещё вчера МетаКуотс-Демо рассчитал всё правильно - сегодня накатили 5664, 5665 - и все ошибки вернулись.
Не могу понять зачем разный расчет делать в разных режимах, если можно одинаковую логику использовать.
Потому что в M1_OHLC_Spread мало данных. Этот режим даже не M1_OHLC[1]_Open[0]_Spread[1]_Spread[0], когда идет анализ срабатывания SL/TP не только на баре, что закончился, но и на начале бара. И даже в таком режиме, если OHLC[1] не удовлетворяют SL, а Open[0] - удовлетворяет, нельзя Open[0] использовать для PositionSELL_SL, т.к. нет данных для Open[0]_Ask.
В общем, мало данных. Поэтому отсутствует проскальзывание у отложенных ордеров и SL/TP.
Потому что в M1_OHLC_Spread мало данных. Этот режим даже не M1_OHLC[1]_Open[0]_Spread[1]_Spread[0], когда идет анализ срабатывания SL/TP не только на баре, что закончился, но и на начале бара. И даже в таком режиме, если OHLC[1] не удовлетворяют SL, а Open[0] - удовлетворяет, нельзя Open[0] использовать для PositionSELL_SL, т.к. нет данных для Open[0]_Ask.
В общем, мало данных. Поэтому отсутствует проскальзывание у отложенных ордеров и SL/TP.
Спред у этих баров есть, а значит вы ошибаетесь про отсутствие Open[0]_Ask.
Насчёт отсутствия проскальзывания внутри свечей согласен, его быть не может, а вот проскальзывания при открытии свечи с гэпом вполне возможно сделать и в режиме тестирования OHLC.
Это значительно приблизило бы тестирование по OHLC к более точным режимам тестирования.
Спред у этих баров есть, а значит вы ошибаетесь про отсутствие Open[0]_Ask.
Это минимальный спред (такое вынужденное официальное заглядывание в будущее) за время жизни всего бара, а не спред на открытии.
Сравните Open[0].ask в разных режимах Тестера.
Заголовок: Баг MetaEditor 5 (Build 5660): Ошибка обновления #property indicator_buffers в проектах (.mqproj)
Приветствую!
Обнаружил критический баг при разработке индикаторов в режиме проекта (.mqproj), который периодически блокирует работу.
Суть проблемы:
При попытке увеличить количество буферов через директиву #property indicator_buffers (например, с 5 до 8), компилятор выдает предупреждение:
"property already exists with different value and will be skipped"
Это происходит рандомно: иногда изменение проходит успешно, но в какой-то момент проект "заклинивает" на старом значении. В результате терминал выделяет память под старое кол-во буферов, что приводит к ошибке "array out of range" при обращении к новым индексам в коде.
Технические данные:
- Терминал: MetaTrader 5 Build 5660.
- ОС: Windows 10.
- Тип файла: Проект (.mqproj) в папке Shared Projects.
Ключевые наблюдения:
1. Ошибка привязана именно к файлу проекта. Если сделать копию основного .mq5 файла в той же папке и скомпилировать её отдельно — ошибка пропадает, и всё работает корректно.
2. Возвращение к старому значению (которое "запомнил" проект) убирает предупреждение.
3. Ошибка проявляется не сразу, а в процессе активной разработки, когда количество буферов меняется несколько раз.
4. Пересоздание проекта помогает, но это плохой вариант (костыль), так как теряется история коммитов в MQL5 Storage и возникают конфликты имен при пуше в гит.
Просьба к разработчикам проверить механизм синхронизации метаданных между .mq5 файлом и .mqproj при компиляции внутри проекта. Похоже, что MetaEditor берет значение из внутреннего кэша проекта, игнорируя актуальный код.
Скриншоты прилагаю:
1) Предупреждение в логах.
2) Исчезновение ошибки при откате значения.
3) Успешная компиляция копии того же кода вне структуры проекта.
Это минимальный спред (такое вынужденное официальное заглядывание в будущее) за время жизни всего бара, а не спред на открытии.
Сравните Open[0].ask в разных режимах Тестера.
А что это меняет? Минимальный он или ещё какой, нам то какая разница?
Есть спред, нет спреда, не важно.
Был гэп, было закрытие позиции по стоп лоссу.
Если мы запишем закрытие позиции по цене открытия свечи или по цене стоп лосса , в каком случае буде меньше погрешность с реальным закрытием (закрытием на более точных режимах тестирования) ?
В общем, мало данных. Поэтому отсутствует проскальзывание у отложенных ордеров и SL/TP.
В моем конкретном примере все данные одинаковые на момент срабатывания SL как в OHLC, так и в Every tick. SL срабатывает на открытии новой свечи и за счет гэпа.При этом режимы "Every tick" берут Bid для DEAL_PRICE_OUT, а OHLC - сам SL. Хотя на первом "даже смоделированном" тике свечи в OHLC режиме у тестера есть ровно те же Ask/Bid, что и в Every tick режимах (скрины).
Получается, в конкретно этом примере причина не в недостатке данных, а именно в разной логике выбора DEAL_PRICE_OUT.
Aleksandr верно подметил, что проскальзывания внутри свечей КОНЕЧНО могут сильно отличаться в разных режимах как раз из-за недостатка данных и их эммуляции в OHLC, но почему на гэпах логика такая разная не понгятно. Если была бы одинаковая, в таких ситуациях можно было бы сильно сблизить OHCL с Every tick.
Насчёт отсутствия проскальзывания внутри свечей согласен, его быть не может, а вот проскальзывания при открытии свечи с гэпом вполне возможно сделать и в режиме тестирования OHLC.
Это значительно приблизило бы тестирование по OHLC к более точным режимам тестирования.