идея у бегуна правильная. наша нормализация именно так и работает. только мы не возводим ничего в степень, а используем готовые константы.
кстати, наш стандартный NormalizeDouble показал правильные результаты (я убрал условие и просто распечатал)
2005.08.09 12:39:27 TestNormalize USDCHF,M15: NormalizeDouble: 1.2407 == 1.2408
у Вас разве не так?
кстати, наш стандартный NormalizeDouble показал правильные результаты (я убрал условие и просто распечатал)
2005.08.09 12:39:27 TestNormalize USDCHF,M15: NormalizeDouble: 1.2407 == 1.2408
у Вас разве не так?
Вот еще один вариант нормализации: dLot = MathFloor(dLot * 10) / 10; (этот пример - до первого знака после запятой)
Кстати, хотелось бы получить от разработчиков ответ - зачем нужна нормализация вообще. То есть, чем цена открытия 1.256 лучше, чем 1.256789?
Кстати, хотелось бы получить от разработчиков ответ - зачем нужна нормализация вообще. То есть, чем цена открытия 1.256 лучше, чем 1.256789?
Кстати, хотелось бы получить от разработчиков ответ - зачем нужна нормализация вообще. То есть, чем цена открытия 1.256 лучше, чем 1.256789?
тем, что цена 1.256 бывает, а цены 1.256789 не бывает
идея у бегуна правильная. наша нормализация именно так и работает. только мы не возводим ничего в степень, а используем готовые константы.
кстати, наш стандартный NormalizeDouble показал правильные результаты (я убрал условие и просто распечатал)
2005.08.09 12:39:27 TestNormalize USDCHF,M15: NormalizeDouble: 1.2407 == 1.2408
у Вас разве не так?
кстати, наш стандартный NormalizeDouble показал правильные результаты (я убрал условие и просто распечатал)
2005.08.09 12:39:27 TestNormalize USDCHF,M15: NormalizeDouble: 1.2407 == 1.2408
у Вас разве не так?
так-то оно так....
если бы у меня не всплывали проблемы с "вашей" нормализацией, я бы велосипед не изобретал бы... а так - не могу сравнить 2 числа - например, старый СЛ с новым при модификации - результат не предсказуем. Приходится извращаться... Я не могу сказать, что мой код безупречен - сейчас как раз дорабатываю-пересматриваю, когда доделаю - скажу, остались ли ошибки..
А вопрос, вообще, заключался в загадочности числа 1.2408. Я пробовал этот скрипт с 2-мя десятками x и y - всё ок. Только этот 1.2408... Прям не знаю...
Кстати, хотелось бы получить от разработчиков ответ - зачем нужна нормализация вообще. То есть, чем цена открытия 1.256 лучше, чем 1.256789?
тем, что цена 1.256 бывает, а цены 1.256789 не бывает
Спросим по-другому. Если я введу цену 1.256789, обязательно будет ошибка? Или будет, но НЕ обязательно? Или все округлится само?
Мне понравилось на англоязычном форуме...
Мы говорим "мои кривые руки", а там прочитал -"my magic fingers" :))
Вот как правильно-то будет, у них или у нас, а? :)
Мы говорим "мои кривые руки", а там прочитал -"my magic fingers" :))
Вот как правильно-то будет, у них или у нас, а? :)
2 Rosh:
правильно будет "мои кривые magic fingers" =)
2 Quark:
по-идее, округлится...хотя...
я когда-то в эксперте сравнивал OrderOpenPrice() для отложенного ордера с округлённой ценой, высчитываемой экспертом - и при одном значении они далеко не всегда были равны (на взгляд МТ). Ордер всё время удалялся и устанавливался заново)))
правильно будет "мои кривые magic fingers" =)
2 Quark:
по-идее, округлится...хотя...
я когда-то в эксперте сравнивал OrderOpenPrice() для отложенного ордера с округлённой ценой, высчитываемой экспертом - и при одном значении они далеко не всегда были равны (на взгляд МТ). Ордер всё время удалялся и устанавливался заново)))
Мне понравилось на англоязычном форуме...
Мы говорим "мои кривые руки", а там прочитал -"my magic fingers" :))
Вот как правильно-то будет, у них или у нас, а? :)
Мы говорим "мои кривые руки", а там прочитал -"my magic fingers" :))
Вот как правильно-то будет, у них или у нас, а? :)
Надо учитывать, что (если читатель достаточно испорчен :) то он непременно вспомнит, что ЕЩЕ означает на современном английском "finger"... Я почти уверен, что так оно и задумывалось :)
А что означает на современном английском "finger"? Неужели именно это? :)
Спросим по-другому. Если я введу цену 1.256789, обязательно будет ошибка? Или будет, но НЕ обязательно? Или все округлится само?
само не округлится и будет ошибка
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
пример скрипта, выявляющего странность:
в общем, только при x = 1.2407 и y = 1.2408 Normalize() и _NormalizeDouble() возвращают "=="...
маразм... сколько не пробовал подставлять других значений - всё ок.
Теперь при сравнении double-ов надо делать их проверку на равенство 1.2408, и только тогда сравнивать? =)))