Проблема с циклами for & while - страница 2

 
VladislavVG:
В цикле while ошибки не было - смотрите внимательней.

А первый как раз нормально работает

вот проверочный скриптик, практически точно такой же как в первом посте

int start()
  {
//----
      int b=Bars-1;
      int k=iBarShift(Symbol(),Period(),StrToTime("2010.04.12 00:00"),false);
      double price=Open[k];
      int i=0;
      while(i<=b)
      {
         if(Open[i]==price)
         {
            string Date=TimeToStr(Time[i]);
            Alert("Дата: ",Date);
            break;
         }
         i++;
      }
      
//----
   return(0);
  }

в случае корректной работы должен выдавать дату  "2010.04.12 00:00"

что он и делает

не знаю почему у автора первый код не работает 

 
knt-kmrd:

А первый как раз нормально работает


У топикстаптера по его словам нет. У Вас работает потому, что Вы взяли значение из массива Open. Только все дело в том, что очень часто это расчетная величина, нормализованная до нужного количества знаков, и, учитывая способ хранения вещественных чисел, Ваш код будет работать не всегда, в отличие от предложенных вариантов ;). Вы видно еще не встречались со случаями, когда в ценовых массивах хранятся ненормализованные цены.

Удачи.

 
VladislavVG:

? Интересно, и как же Вы предопределенную переменную 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 в нечто аморфное которое непонятно как применять к финансам требующим

решений высокой точности. Подобные проблемы ставят любого брокера в более выгодное положение с трейдером.








 
JohnOne:


Решение предоставленное выше. к сожалению нельзя признать дееспособным хотя бы по тому что сравниваемые величины после округления терминалом по неизвестному встроенному алгоритму



Сразу три неточности:

1. Решение, что я выше представил не требует предварительной нормализации и работает ВСЕГДА, как вариант - просто задается требуемая точность.

2. Алгоритм нормализации известен - есть масса аналогичных вопросов на форуме, поищите.

3. В мкл нет проблем с double: так в любом языке.

По поводу поиска точек пересечения :

Ведь торговый сигнал генерируется пересечениям кривых, а факт пересечения устанавливается равенством значения кривых в точке пересечения.

спасибо, повеселили. По секрету : пересечения определяются сменой знака разности.

Удачи.

ЗЫ Почитайте документацию. Такое впечатление, что мкл - это первый Ваш опыт в программировании. Подсказка: Алерт и Принт в мкл работают с точностью 4-ре знака и об этом написано в документации. Проверять с их помощью значения "в лоб" "не совсем" корректно. Это тоже обсуждалось на форуме.

 

К вопросу об округлении.

В процедурах Print() и Alert() по умолчанию величины double округляются до 4 знаков.

если требуется другая точность округления, то востользуйтесь DoubleToStr()

Причина обращения: