ФорумРазделы

Ошибки, баги, вопросы - страница 616

Новый комментарий

Вопрос разработчикам:

почему в тестере невозможно получить поле структуры  

MqlTradeResult  price;            // Цена в сделке, подтверждённая брокером ?  Выдает 0. 

На демо нормально работает. 

x100intraday:

 Есть ли какая-либо взаимосвязь между списочной структурой таймфреймов и флагов видимости объектов (ведь даже длина списков разная: 22 vs 23)? Вообще, спрашиваю для того, чтобы эффективно и компактно назначать видимость объектов на таймфреймах в цикле с заданными границами, а не перечислять и суммировать вручную флаги. Какой логикой воспользоваться, если взят наугад произвольный таймфрейм, на нём построен графический объект и нужно разрешить его видимость на всех таймфреймах не старше текущего (т. е. того самого, на котором он был построен)? Алгоритм должен быть универсальным, а не для одного конкретного случая. С поиндексной корреляцией - уже в пролёте, нету здесь никакого даже индексного соответствия. Парсить строки имён и сравнивать - опять же в пролёте из-за невозможности работать со строкой в случае с константами видимости. Пока на ум приходит сложная, туманная и очень кривая реализация.

Взаимосвязь конечно есть, но она до того неявная, что написать <флаг_видимости>=F(<таймфрейм>) получится только так:

int PeriodToTimeframeFlag(ENUM_TIMEFRAMES period)
  {
   flags=0;
   static ENUM_TIMEFRAMES _p_int[]={PERIOD_M1, PERIOD_M2, PERIOD_M3, PERIOD_M4, PERIOD_M5, PERIOD_M6,
                                    PERIOD_M10,PERIOD_M12,PERIOD_M15,PERIOD_M20,PERIOD_M30,
                                    PERIOD_H1, PERIOD_H2, PERIOD_H3, PERIOD_H4, PERIOD_H6, PERIOD_H8,PERIOD_H12,
                                    PERIOD_D1, PERIOD_W1, PERIOD_MN1};
//--- cycle for all timeframes
   for(int i=0;i<ArraySize(_p_int);i++)
      if(period==_p_int[i])
        {
         //--- at the same time generate the flag of the working timeframe
         flags=((int)1)<<i;
         break;
        }
   return(flags);
  }

x100intraday:

Какой логикой воспользоваться, если взят наугад произвольный таймфрейм, на нём построен графический объект и нужно разрешить его видимость на всех таймфреймах не старше текущего (т. е. того самого, на котором он был построен)?

если надо таки не шашечки)

ENUM_TIMEFRAMES TF[21]={PERIOD_M1,PERIOD_M2,PERIOD_M3,PERIOD_M4,PERIOD_M5,PERIOD_M6,PERIOD_M10,
                     PERIOD_M12,PERIOD_M15,PERIOD_M20,PERIOD_M30,PERIOD_H1,PERIOD_H2,PERIOD_H3,
                     PERIOD_H4,PERIOD_H6,PERIOD_H8,PERIOD_H12,PERIOD_D1,PERIOD_W1,PERIOD_MN1};

int Visibility[21]={1,3,7,15,31,63,127,255,511,1023,2047,4095,8191,
            16383,32767,65535,131071,262143,524287,1048575,2097151};

рассматриваем TF[i], задаём Visibility[i]..

или видимость=(int)(MathPow(2,i+1)-1);

Swan:

если надо таки не шашечки)

рассматриваем TF[i], задаём Visibility[i]..

или видимость=(int)(MathPow(2,i+1)-1);

 Спасибо за формулу видимости - может, куда приспособлю. Было видно по значениям на таймфреймах, что это степень чего-то, но пытаться самостоятельно восстановить формулу не пробовал.

 А разве -1 надо? Вообще, Visibility[], по-моему, заполнен некорректными значениями, в действительности же должно быть везде без -1, то есть: 1, 2, 4, 8, 16...

uncleVic:

Взаимосвязь конечно есть, но она до того неявная, что написать <флаг_видимости>=F(<таймфрейм>) получится только так:


 Спасибо, изящно. Всё именно так и пытался сделать, окромя собственно сдвига, его-то мне и не хватало.

  И в конечном счёте обращался я собственно по вопросу вычисления значений флага на каждом витке регрессионного цикла по массиву таймфреймов _p_int (что-то ведь в итоге нужно будет складывать пофлагово), а не только на одном текущем. Ну получили мы сдвигом значение флага видимости на текущем ТФ, а потом с каждым витком i-- должно где-то что-то меняться... Там либо формулу возведения в степень нужно прикладывать, либо тот же принцип сдвига использовать. Пока ещё не сообразил как...

 ...Хотя да, это же функция с ТФ-аргументом - её в цикле попробую покрутить...

 Впрочем, опять не то. Сейчас поясню. В примере заведён static ENUM_TIMEFRAMES _p_int[] на 21 элемент, но! Хотелось бы вот чего: у меня уже есть подобный массив, но он может быть произвольной длины. Это массив, содержащий те таймфреймы, на которых будет что-то строиться, но видимость-то должна у них быть и на всех младших таймфреймах, а ими ни один массив не забит ни отдельно, ни дополнен из существующих. То есть здесь-то я и упоминаю необходимость на лету, отплясывая от текущего ТФ, в регрессионном цилке вычислять флаги с текущего и всех младших таймфреймов и суммировать их. Фишка имеенно в том, чтобы не создавать полный массив предзаданных значений чего-либо (хоть таймфреймов, хоть флагов видимости) и шерстить их, а вычислять в уме на каждом витке только для неполного массива предзаданных для работы таймфреймов.

 Пойду пока поразбираюсь, если застряну, спрошу. 

 Я почему (int)(MathPow(2,i+1)-1) или ((int)1)<<i не спешу использовать-то... Раз есть i, то спокойно можно подставлять в цикл и прогонять... Но как в случае с возведением в степень, так и в случае со сдвигом - надёжно ли это всегда? А то ведь если вдруг разработчики когда-нибудь добавят новые таймфреймы, не поползёт ли вся логика под откос? Навскидку - в примере со сдвигом мы ожидаем совпадения текущего периода с предзаданным:

if(period==_p_int[i])
поэтому, даже если в реальном случае какие-то таймфеймы из теоретически полной последовательности будут пропущены или эта последовательность будет расширена разработчиками, логика не должна поползти. А вот если б мы полагались на чистую математику и просто гнали бы цикл по формуле от границы к границе, не оглядываясь на возможное отсутствие или присутствие новых таймфреймов, то рано или поздно, в очередном билде, получили бы, вестимо, перекос...
x100intraday:

 Я почему (int)(MathPow(2,i+1)-1) или ((int)1)<<i не спешу использовать-то... Раз есть i, то спокойно можно подставлять в цикл и прогонять... Но как в случае с возведением в степень, так и в случае со сдвигом - надёжно ли это всегда? А то ведь если вдруг разработчики когда-нибудь добавят новые таймфреймы, не поползёт ли вся логика под откос? Навскидку - в примере со сдвигом мы ожидаем совпадения текущего периода с предзаданным:

поэтому, даже если в реальном случае какие-то таймфеймы из теоретически полной последовательности будут пропущены или эта последовательность будет расширена разработчиками, логика не должна поползти. А вот если б мы полагались на чистую математику и просто гнали бы цикл по формуле от границы к границе, не оглядываясь на возможное отсутствие или присутствие новых таймфреймов, то рано или поздно, в очередном билде, получили бы, вестимо, перекос...

 

Опасения очень обоснованные. Вышеприведённый код оправдывает только то, что набор флагоф видимости - фактически макрос.

Правильнее будет работать через:

int result=0;
//---
switch(period)
  {
   case PERIOD_M1: result=OBJ_PERIOD_M1; break;
   case PERIOD_M2: result=OBJ_PERIOD_M2; break;
   case PERIOD_M3: result=OBJ_PERIOD_M3; break;
   case PERIOD_M4: result=OBJ_PERIOD_M4; break;
   case PERIOD_M5: result=OBJ_PERIOD_M5; break;

//--- и так далее

   default: print("Что-то новенькое");
  }
Документация по MQL5: Стандартные константы, перечисления и структуры / Константы объектов / Видимость объектов
Документация по MQL5: Стандартные константы, перечисления и структуры / Константы объектов / Видимость объектов
  • www.mql5.com
Стандартные константы, перечисления и структуры / Константы объектов / Видимость объектов - Документация по MQL5
x100intraday:

 Спасибо за формулу видимости - может, куда приспособлю. Было видно по значениям на таймфреймах, что это степень чего-то, но пытаться самостоятельно восстановить формулу не пробовал.

 А разве -1 надо? Вообще, Visibility[], по-моему, заполнен некорректными значениями, в действительности же должно быть везде без -1, то есть: 1, 2, 4, 8, 16...

1,2,4 и т.д. - видимость обьекта на одном тф. =MathPow(2,i);

на текущем и меньших 1, 1+2, 1+2+4, 1+2+4+8 и т.д., таки =MathPow(2,i+1)-1;

В двоичном коде наглядней..

uncleVic:

Опасения очень обоснованные. Вышеприведённый код оправдывает только то, что набор флагоф видимости - фактически макрос.

Правильнее будет работать через:

Тож самое в принципе. При изменении в списке тф придётся редактировать код.

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


 x100intraday:

Впрочем, опять не то. Сейчас поясню. В примере заведён static ENUM_TIMEFRAMES _p_int[] на 21 элемент, но! Хотелось бы вот чего: у меня уже есть подобный массив, но он может быть произвольной длины. Это массив, содержащий те таймфреймы, на которых будет что-то строиться, но видимость-то должна у них быть и на всех младших таймфреймах, а ими ни один массив не забит ни отдельно, ни дополнен из существующих. То есть здесь-то я и упоминаю необходимость на лету, отплясывая от текущего ТФ, в регрессионном цилке вычислять флаги с текущего и всех младших таймфреймов и суммировать их. Фишка имеенно в том, чтобы не создавать полный массив предзаданных значений чего-либо (хоть таймфреймов, хоть флагов видимости) и шерстить их, а вычислять в уме на каждом витке только для неполного массива предзаданных для работы таймфреймов.

не, неполучится. Соответствие тф и видимости придётся задать. Или два соответствующих массива, иль вариант со switch.

+массив с теми тф которые нужны, +в инит расчитать по всем этим данным видимость обьекта для каждого используемого TF. Как-то так..)

Всю голову сломал, не пойму в чем дело?

double VirtualSL;
MqlTick tick;
//+------------------------------------------------------------------+
//| Expert initialization function                                   |
//+------------------------------------------------------------------+
int OnInit()
  {
   VirtualSL=0.0;
   return(0);
  }
//+------------------------------------------------------------------+
//| Expert tick function                                             |
//+------------------------------------------------------------------+
void OnTick()
  {
   trail();
  }
//+------------------------------------------------------------------+
void trail()
  {
   double stopcal;

   SymbolInfoTick(_Symbol,tick);
   stopcal=tick.bid;

//   if((VirtualSL!=0.0 && stopcal>VirtualSL) || VirtualSL==0.0) // так все работает

   if(VirtualSL==0.0 || (VirtualSL!=0.0 && stopcal>VirtualSL)) // так не хочет работать
     {
      VirtualSL=stopcal;
      Print("use Ok!");
     }
   if(VirtualSL<stopcal) Print("o_O ((((( stopcal = ",stopcal,"   VirtualSL = ",VirtualSL);
  }
//+------------------------------------------------------------------+

 

2011.12.29 01:16:07 Core 1 2011.09.26 02:54:13   o_O ((((( stopcal = 1.54508   VirtualSL = 1.53378

2011.12.29 01:16:07 Core 1 2011.09.26 02:54:12   o_O ((((( stopcal = 1.54507   VirtualSL = 1.53378

2011.12.29 01:16:07 Core 1 2011.09.26 02:54:12   o_O ((((( stopcal = 1.54508   VirtualSL = 1.53378


her.human:

Всю голову сломал, не пойму в чем дело?

Ошибка в оптимизаторе компилятора. Спасибо за сообщение, исправим.

Ошибка возникает при такой конструкции

if(VirtualSL==0.0 || (VirtualSL!=0.0 && stopcal>VirtualSL))
if(VirtualSL<stopcal)
В условии первого if из второй части можно убрать VirtualSL!=0.0 т.к. после проверки первой части условия это выражение всегда истина. При этом ошибка оптимизатора пропадёт.


Исправлено, исправление войдёт в следующий билд.
1...609610611612613614615616617618619620621622623...3776
Новый комментарий