Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
В цикле while ошибки не было - смотрите внимательней.
А первый как раз нормально работает
вот проверочный скриптик, практически точно такой же как в первом посте
в случае корректной работы должен выдавать дату "2010.04.12 00:00"
что он и делает
не знаю почему у автора первый код не работает
А первый как раз нормально работает
У топикстаптера по его словам нет. У Вас работает потому, что Вы взяли значение из массива Open. Только все дело в том, что очень часто это расчетная величина, нормализованная до нужного количества знаков, и, учитывая способ хранения вещественных чисел, Ваш код будет работать не всегда, в отличие от предложенных вариантов ;). Вы видно еще не встречались со случаями, когда в ценовых массивах хранятся ненормализованные цены.
Удачи.
? Интересно, и как же Вы предопределенную переменную Open нормализовали ?
Лень повторяться: это (подчеркнутое), при условии вещественных типов, неверно практически для любого языка программирования. Ищите по форуму. Один из вариантов:
Решение предоставленное выше. к сожалению нельзя признать дееспособным хотя бы по тому что сравниваемые величины после округления терминалом по неизвестному встроенному алгоритму
могут отличится не только на один пипс, но и на десятки пипсов, о чём описано ниже подробнее...Причём эта величина колебания непредсказуема!
- у меня есть два значения из двух разных буферов, для дальнейшего анализа мне нужно знать равны ли эти значения между в точности, и в случаи их неровности узнать какое значение
из них больше.
Если выводить эти значения через Алерт то они одинаковы: Buff1[i] = 1.286 Buff2[i] =1.286
Если сравнивать єти два буферных значения через :
if (MathAbs( Buff1[i]-Buff2[i] )<Point*0.5)
то MathAbs( Buff1[i]-Buff2[i] ) возвращает значение 0.0001, а цена Point=0.00001, ну и тут получается что эти значения между собой НЕ ровны.
--- ну если принять во внимание то что в MQL есть проблемы с double, как сказал SofTAA:
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
- Язык прекрасно работает с операциями сравнения, но вы пытаетесь проверить на равенство double. Это плохая практика в любом языке программирования.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
то я пошел попробовал по другому способу:
Я записал double в string и попытался их сравнить:
string Buff1ToSTR=DoubleToStr(Buff1[i],5);
string Buff2ToSTR=DoubleToStr(Buff2[i],5);
if (Buff1ToSTR==Buff2ToSTR)
Alert ("значения ровны");
- Но этот оператор выводит следующие значения через Alert: значения которые были записаны в Buff1ToSTR= 1.28602 и в Buff2ToSTR=1.28595, и тут получается что это два буфера между собой НЕ ровны.
- я попробовал назад переписать значения с string в double и получаю Buff1ToSTRToDouble= 1.286 и вBuff1ToSTRToDouble=1.2859
Вопрос:
Я нуждаюсь в универсальном способе сравнения этих точек вне зависимости от разрядности их значений, мне нужно анализировать не два значения а около сотни, и мне нужен точный анализ для принятия правильного решения, эта точность не является моею прихотью, а необходимостью получения корректного торгового сигнала. Ведь торговый сигнал генерируется пересечениям кривых, а факт пересечения устанавливается равенством значения кривых в точке пересечения. И если мы не имеем инструмента сравнения с необходимой точностью то
это означает: что пересечении мы фиксируем не в том месте где оно фактически произошло, а со значительным опозданием вызванным погрешностью сравнения, в результате ценность торгового сигнала сводится к нулю.
Кроме того для меня остаётся загадкой как вообще такими техническими средствами можно строить жизнеспособною торговую систему??? И как вообще можно достичь какой либо цели, приблизившись к которой мы не располагаем средствам идентификации которым можно доверять. В то время, когда брокер при идентификации торговой сделки работает с точностью до 1 пипса, мы располагаем средствами сравнения данных в языке MQL расхождение в которых может достигать и 70 пипсов в 5-значимой системой.
То логарифмическая линейка времён 1 Мировой Войны работала гораздо с более высокой точностью.
Работая в терминале предоставляющем 5-знаковые котировки не трудно заметить что в данных индикаторных кривых их значения округляются терминалом с точностью до 4,3 и даже 2 значений после запетой. Если такие данные преобразовать в строковою переменною то эти округлённые 3-4 значение значения приобретают больше знаков чем преобразовываемая величина с плавающею запетой и эти значения не нулевые, и тогда возникает вопрос: По какому алгоритму, и зачем система округляет не нулевые значения ухудшая точность данных причём в каждом конкретном случаи мы можем иметь разную погрешность. Выше указанным образом язык MQL превращает переменные двойной точности double в нечто аморфное которое непонятно как применять к финансам требующим
решений высокой точности. Подобные проблемы ставят любого брокера в более выгодное положение с трейдером.
Решение предоставленное выше. к сожалению нельзя признать дееспособным хотя бы по тому что сравниваемые величины после округления терминалом по неизвестному встроенному алгоритму
Сразу три неточности:
1. Решение, что я выше представил не требует предварительной нормализации и работает ВСЕГДА, как вариант - просто задается требуемая точность.
2. Алгоритм нормализации известен - есть масса аналогичных вопросов на форуме, поищите.
3. В мкл нет проблем с double: так в любом языке.
По поводу поиска точек пересечения :
спасибо, повеселили. По секрету : пересечения определяются сменой знака разности.
Удачи.
ЗЫ Почитайте документацию. Такое впечатление, что мкл - это первый Ваш опыт в программировании. Подсказка: Алерт и Принт в мкл работают с точностью 4-ре знака и об этом написано в документации. Проверять с их помощью значения "в лоб" "не совсем" корректно. Это тоже обсуждалось на форуме.
К вопросу об округлении.
В процедурах Print() и Alert() по умолчанию величины double округляются до 4 знаков.
если требуется другая точность округления, то востользуйтесь DoubleToStr()