Ошибки, баги, вопросы - страница 433
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Renat, если можно, обратите внимание, пожалуйста, на заявку #124661 в СД.
С 13 июня жду ответа.
Renat, если можно, обратите внимание, пожалуйста, на заявку #124661 в СД.
С 13 июня жду ответа.
Так Вам неоднократно давался правильный ответ. Ответил Вам еще раз.
Так Вам неоднократно давался правильный ответ. Ответил Вам еще раз.
Не вижу ответа в этой заявке. Последний комментарий в ней мой от 2011.06.21 09:25 (повторное напоминание об актуальности вопроса).
Дублирую на всякий случай сюда:
Правильно ли я понимаю, что ограничение на минимальный объем/лот сделки/ордера актуально лишь для открытия позиции?
На сделки/ордера, результатом которых будут закрытие, наращивание, сокращение или переворот позиции - данное требование не распространяется?
Ограничение на минимальный шаг сделки распространяется на все 5 (пять) вышеуказанных сценариев.
Вроде как все возможные сценарии описаны. Или есть еще какие-то кроме этих 5 (пяти)?
Вам дважды отвечали, потом ответил я.
Отвечу еще раз - да, на полное закрытие не распространяется правило лимитов объемов.
Речь идет об увеличении скорости MQL5?
Вам дважды отвечали, потом ответил я.
Отвечу еще раз - да, на полное закрытие не распространяется правило лимитов объемов.
Renat, не поймите меня неправильно. Повторяю свой вопрос не баловства ради, а уточнения для.
Пока Ваш ответ и ваших коллег (в СД) касается 2 (двух) сценариев: 1) открытие позиции, 2) полное закрытие позиции (вероятно, с обязательным применением ORDER_FILLING_AON).
Результатом исполнения ордера (сделки) может быть еще, как минимум, 3 (три) сценария: наращивание, сокращение или переворот позиции.
К сожалению, явного уточнения по этим трем сценариям я не нахожу в ответах от MQ. :(
Для наглядности, приведу несколько примеров (во всех случаях на сервере минимальный лот = 1.0; минимальный шаг = 0.1):
Пример №1 (сокращение позиции).
Имеется длинная позиция объемом 1.0. Пытаемся полностью закрыть позицию (применяя ORDER_FILLING_CANCEL). Отправляем ордер на продажу объемом 1.0 лот. Ордер исполняется частично (0.9 лота).
Результат по инструменту имеется незакрытая длинная позиция объемом 0.1 лота. Таким образом, делаем вывод, что для сценария сокращения позиции требование на объем минимального лота не действует.
Пример №2 (переворот позиции).
Имеется длинная позиция объемом 0.1 лот. Отправляю на сервер ордер на продажу объемом 0.2 лота. Сервер пример такой ордер? (требования к минимальному лоту опять не соблюдаются).
Пример №3 (наращивание позиции).
Имеется длинная позиция объемом 0.1 лот. Отправляю на сервер ордер на покупку объемом 0.1 лота. Сервер пример такой ордер?
Для наглядности, приведу несколько примеров (во всех случаях на сервере минимальный лот = 1.0; минимальный шаг = 0.1):
Пример №1 (сокращение позиции).
Имеется длинная позиция объемом 1.0. Пытаемся полностью закрыть позицию (применяя ORDER_FILLING_CANCEL). Отправляем ордер на продажу объемом 1.0 лот. Ордер исполняется частично (0.9 лота).
Результат по инструменту имеется незакрытая длинная позиция объемом 0.1 лота. Таким образом, делаем вывод, что для сценария сокращения позиции требование на объем минимального лота не действует.
Если позиция закроется частично по 0.9 (причем ордер на 1.0), значит придется еще раз послать заявку на закрытие остатка в 0.1.
Причем, если исполнение идет на внешнем шлюзе, то велика вероятность, что и закрыть дадут только сразу весь объем в 1.0, не позволяя делить.
Пример №2 (переворот позиции).
Имеется длинная позиция объемом 0.1 лот. Отправляю на сервер ордер на продажу объемом 0.2 лота. Сервер пример такой ордер? (требования к минимальному лоту опять не соблюдаются).
Пример №3 (наращивание позиции).
Имеется длинная позиция объемом 0.1 лот. Отправляю на сервер ордер на покупку объемом 0.1 лота. Сервер пример такой ордер?
Конечно нет.
Читайте, пожалуйста, правила буквально и не пытайтесь придумывать свои условия. Правило простое "при ликвидации позы в НОЛЬ правило лимитов объемов может не действовать". Это правило неоднократно было озвучено.
Также надо принимать во внимание, что любой брокер или любой биржевой шлюз может использовать свои собственные, более жесткие правила контроля объемов.
Максимальное количество строк, между которыми будет работать подсветка открывающих/закрывающих скобок - 128. Это ограничение было введено потому, что нет смысла подсвечивать открывающую и закрывающую скобки, которые не умещаются на один экран. Кроме того после введения этого ограничения существенно увеличилось быстродействие работы MetaEditor.
Не принципиальный вопрос, но все же. Конкатенация строк. В документации описаны две функции StringAdd и StringConcatenate.
...
Результат:
2011.06.26 19:10:55 test (EURUSD,H1) №1 2012 milliseconds, i = 10000000
2011.06.26 19:11:04 test (EURUSD,H1) №2 8269 milliseconds, i = 10000000
2011.06.26 19:11:10 test (EURUSD,H1) №3 6661 milliseconds, i = 10000000
Выходит, все же, обычное сложение быстрее.
Пример некорректный.
В первом методе должно быть "result = result + string1 + string2 + string3;"
И я бы сделал разные result для всех 3-х тестов, а то они в неравных условиях стартуют (уже выделено какое-то кол-во памяти).
Еще лучше - разнести тесты в разные скрипты и запускать последовательно.
У меня получилось вот так:
1. length = 10`000
2011.06.27 02:43:05 sStingTest (EURUSD,M1) №2 0 milliseconds, i = 10000
2011.06.27 02:43:05 sStingTest (EURUSD,M1) №3 0 milliseconds, i = 10000
2. length = 100`000
2011.06.27 02:37:39 sStingTest (EURUSD,M1) №3 15 milliseconds, i = 1000000
Окончания №1 - не дождался
3. length = 1`000`000
2011.06.27 02:37:39 sStingTest (EURUSD,M1) №3 187 milliseconds, i = 1000000
Окончания №1 - не дождался
4. length = 10`000`000
На 2-м тесте в журнал начинает сыпаться ошибка "MemoryException: 602492946 bytes not available", скрипт удалял вручную.
Вывод: StringConcatenate самый быстрый.
В спарвке к ф-ции StringAdd, кстати, тоже не очень корректный пример сравнения.
Мой код для проверки - в прицепе.