Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
А ничего, что в предыдущем вопросе была input переменная, а тут простая?
Мне лениво проверять… Так-что можете не обращать внимания…
Input должен соответствовать размерности принимаемых данных. Datetime - восьмибайтовый формат.
Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий
Функции подсчета прибыли/убытка
forex2030, 2022.02.17 19:33
Интересно, ответит на вопрос?))
Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий
Функции подсчета прибыли/убытка
Aleksandr Volotko, 2022.02.17 19:35
должен... зря что ли три года ждал?.. обязательно ответит! ))
Столкнулся в билде 1353 с такой ситуацией.
И на выходе получаю вот такое:
2022.03.28 11:15:05.500 2022.02.03 00:00:00 EA_Lock_ver2 EURUSD,H4: FromString=0.9325599999999999
2022.03.28 11:15:05.500 2022.02.03 00:00:00 EA_Lock_ver2 EURUSD,H4: String=0.93256000
2022.03.28 11:15:05.500 2022.02.03 00:00:00 EA_Lock_ver2 EURUSD,H4: Norm=0.9325599999999999
2022.03.28 11:15:05.500 2022.02.03 00:00:00 EA_Lock_ver2 EURUSD,H4: Origin=0.9325599999999999
После последнего обновления МТ4 не происходит подключение счетов.
Версия 1355 от 16 марта 2022
Столкнулся в билде 1353 с такой ситуацией.
И на выходе получаю вот такое:
2022.03.28 11:15:05.500 2022.02.03 00:00:00 EA_Lock_ver2 EURUSD,H4: FromString=0.9325599999999999
2022.03.28 11:15:05.500 2022.02.03 00:00:00 EA_Lock_ver2 EURUSD,H4: String=0.93256000
2022.03.28 11:15:05.500 2022.02.03 00:00:00 EA_Lock_ver2 EURUSD,H4: Norm=0.9325599999999999
2022.03.28 11:15:05.500 2022.02.03 00:00:00 EA_Lock_ver2 EURUSD,H4: Origin=0.9325599999999999
Это обычное дело при работе с вещественными числами.
Решение для отображения значения: установить нужную точность (у DoubleToString есть второй аргумент, указывающий точность).
Решение для сравнения: сравнивать абсолютную разность двух чисел с величиной заданной погрешности. К примеру, цены лучше всего сравнивать так:
Это обычное дело при работе с вещественными числами.
Решение для отображения значения: установить нужную точность (у DoubleToString есть второй аргумент, указывающий точность).
Решение для сравнения: сравнивать абсолютную разность двух чисел с величиной заданной погрешности. К примеру, цены лучше всего сравнивать так:
Спасибо за ответ, он верный, все будет работать правильно. Но мой вопрос был немного в другом. Я говорю о "рассыпании" исходного числа. Я задаю переменной конкретное, конечное значение (lTmp= 0.93256), но после вызова функции NormalizeDouble для этой переменной - функция возвращает другое число (0.9325599999999999). Эта ошибка функция NormalizeDouble() сыграла плохую роль в реальной ситуации: есть некий расчет цены, на уровне которой надо создать стоповый ордер. В результате вычислений последним действием стоит вызов функции нормализации и уже после этого вызывается функция создания стопового ордера. Так вот, функция создания ордера стала возвращать ошибку и ордер не создавался. Пошаговый разбор выявил эту ситуацию: расчетное число было 0.93256, а в функцию создания ордера передавалось число после нормализации немного другое о ордер не создавался. Эта ошибка именно с этим числом 0.93256. С другими числами такого бага не обнаружено.
Спасибо за ответ, он верный, все будет работать правильно. Но мой вопрос был немного в другом. Я говорю о "рассыпании" исходного числа. Я задаю переменной конкретное, конечное значение (lTmp= 0.93256), но после вызова функции NormalizeDouble для этой переменной - функция возвращает другое число (0.9325599999999999). Эта ошибка функция NormalizeDouble() сыграла плохую роль в реальной ситуации: есть некий расчет цены, на уровне которой надо создать стоповый ордер. В результате вычислений последним действием стоит вызов функции нормализации и уже после этого вызывается функция создания стопового ордера. Так вот, функция создания ордера стала возвращать ошибку и ордер не создавался. Пошаговый разбор выявил эту ситуацию: расчетное число было 0.93256, а в функцию создания ордера передавалось число после нормализации немного другое о ордер не создавался. Эта ошибка именно с этим числом 0.93256. С другими числами такого бага не обнаружено.
Дело в том, что числа в памяти представлены не в десятичной системе счисления, а в двоичной. Многие десятичные числа (с плавающей точкой) не имеют точного эквивалента в двоичной системе. Получается бесконечная дробь, которая при переводе в десятичную систему дает погрешность. Вот здесь об этом подробнее.
Дело в том, что числа в памяти представлены не в десятичной системе счисления, а в двоичной. Многие десятичные числа (с плавающей точкой) не имеют точного эквивалента в двоичной системе. Получается бесконечная дробь, которая при переводе в десятичную систему дает погрешность. Вот здесь об этом подробнее.
Согласен. Как решить эту ситуацию, чтобы ордера могли открываться по этой цене ?
Согласен. Как решить эту ситуацию, чтобы ордера могли открываться по этой цене ?
Если речь о том, чтобы установить отложенный ордер по такой цене, то цену нужно привести к точности тика. Вот так:
Если речь о том, чтобы открыть рыночный ордер по заданной цене, то следует учитывать, что такой цены может и не быть (цена перепрыгнет через этот уровень). Таким образом, можно говорить лишь о том, что ордер открывается в случае пересечения ценой заданного значения. Поэтому ставятся условия для пересечения уровня вниз и вверх. Вниз: предыдущий тик был выше значения, а текущий - ниже или равен. Вверх: предыдущий тик был ниже значения, а текущий - выше или равен.
Если речь о том, чтобы установить отложенный ордер по такой цене, то цену нужно привести к точности тика. Вот так:
Если речь о том, чтобы открыть рыночный ордер по заданной цене, то следует учитывать, что такой цены может и не быть (цена перепрыгнет через этот уровень). Таким образом, можно говорить лишь о том, что ордер открывается в случае пересечения ценой заданного значения. Поэтому ставятся условия для пересечения уровня вниз и вверх. Вниз: предыдущий тик был выше значения, а текущий - ниже или равен. Вверх: предыдущий тик был ниже значения, а текущий - выше или равен.
согласен, спасибо. Но все же, я считаю, что в MQL4 ошибка по работе с этим, конкретным числом (0.93256). Если это так - чтобы ее поправили разработчики. В других языках программирования округление до 5 знаков этого значения типа double - работает как надо.