Errors, bugs, questions - page 616

[Serj]

Question for developers:

Why in the tester it is not possible to get the field of the structure

MqlTradeResultprice;// Price in a trade, confirmed by the broker? It gives 0.

It works fine on demo.

[Victor Kirillin]

x100intraday:

Is there any relationship between the list structure of timeframes and object visibility flags (because even the length of lists is different: 22 vs 23)? In general, I'm asking in order to efficiently and compactly assign visibility of objects on timeframes in a cycle with given boundaries, rather than to list and summarize flags manually. What logic to use if an arbitrary timeframe is taken at random, a graphical object is built on it and it needs to be allowed to be visible on all timeframes not older than the current one (i.e. the one it was built on)? The algorithm should be universal, not for one particular case. The index correlation is already screwed, there is not even an index match. Parsing strings of names and comparing is again a failure because of impossibility to handle string in case of visibility constants. So far, a complicated, vague and very crooked implementation comes to mind.

Of course there is a correlation, but it is so implicit that the only way to write <visibility_flag> = F(<timeframe>):

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);
  }

[Aleksey Lebedev]

x100intraday:

What logic to use if we take at random an arbitrary timeframe, build a graphical object on it and need to allow its visibility on all timeframes not older than the current one (i.e. the one it was built on)?

if it is not a checker)

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};

Consider TF[i], set Visibility[i]...

or visibility=(int)(MathPow(2,i+1)-1);

[x572intraday]

Swan:

If you need it, then it is not a checkerboard)

Consider TF[i], set Visibility[i]...

or visibility=(int)(MathPow(2,i+1)-1);

Thanks for the Visibility formula - maybe I'll adapt it. It was obvious from values on timeframes, that it is a degree of something, but I haven't tried to reconstruct the formula myself.

Is -1 needed? In general, Visibility[] seems to be filled with incorrect values, in fact it should be everywhere without -1, i.e.: 1, 2, 4, 8, 16...

[x572intraday]

uncleVic:

Of course there is a relationship, but it's so implicit that the only way to write <visibility_flag>=F(<timeframe>) is to do it that way:

Thank you, elegant. That's exactly what I was trying to do, except for the shift itself, which is exactly what I was missing.

And in the end I actually addressed the question of calculating the flag values on each turn of regression loop over an array of _p_int timeframes (in the end something will have to be added in flags), not only on the current one. Well, by shifting the visibility flag value at the current timeframe, and then with every rotation of i-- something should change somewhere... Either the exponentiation formula must be applied there or the same shift principle must be used. I haven't figured out how yet...

... Although, yes, it's a function with TF-argument - I'll try to loop it...

However, it's wrong again. Let me explain. In the example, there is static ENUM_TIMEFRAMES _p_int[] for 21 items, but here's what I want: I already have such an array, but it can be of any length. It is an array containing the timeframes, on which something will be built. But they should also be visible on all lower timeframes and none of the arrays is filled with them separately or additionally from the existing ones. So here I am mentioning the necessity to calculate flags of the current and all lower timeframes and sum them up in the regression loop on the fly, dancing from the current timeframe. The trick is not to create a complete array of preset values of anything (even of timeframes or visibility flags) and fiddle with them, but to calculate in my mind for each turn only the incomplete array of preset timeframes.

I'll go for a while and if I get stuck, I'll ask.

[x572intraday]

Why am I in no hurry to use (int)(MathPow(2,i+1)-1) or ((int)1)<<i... Since i is there, you may easily substitute it into a loop and run... But, just like in case of multiplication and shifting - will it always be safe? Suppose the developers ever add new timeframes, won't the entire logic go astray? Right off the bat - in the example with a shift we are expecting the current period to coincide with the preset one:

if(period==_p_int[i])

so even if in the real case some timeframes from the theoretically complete sequence are omitted or this sequence is extended by the developers, the logic should not crawl. But if we rely on pure mathematics and just run the cycle by formula from border to border, without looking at possible absence or presence of new timeframes, then sooner or later, in the next build, we would get skewed...

[Victor Kirillin]

x100intraday:

Why am I in no hurry to use (int)(MathPow(2,i+1)-1) or ((int)1)<<i... If i is there, you may easily substitute it into a loop and run... But, just like in case of multiplication and shifting - is it always safe? Suppose the developers ever add new timeframes, won't the entire logic go astray? Just off the top - in the example with a shift, we expect the current period to be the same as the preset one:

so even if in the real case some timeframes from the theoretically complete sequence are omitted or this sequence is extended by the developers, the logic should not creep in. But if we rely on pure mathematics and just run the cycle by the formula from border to border, without paying attention to possible absence or presence of new timeframes, then sooner or later, in the next build, we would get a skew...

Our concerns are very reasonable. The code above justifies the fact that the visibility flag set is actually a macro.

It would be more correct to work through:

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("Что-то новенькое");
  }

[Aleksey Lebedev]

x100intraday:

Thanks for the visibility formula - maybe I'll adapt it. I could see from the values on the timeframes that it was a degree of something, but I haven't tried to reconstruct the formula myself.

Is -1 really necessary? Actually, Visibility[] seems to be filled in incorrectly, in fact, it should be everywhere without -1, i.e. 1, 2, 4, 8, 16...

1,2,4 etc. - visibility of the object on one timeframe. =MathPow(2,i);

on current and smaller 1, 1+2, 1+2+4, 1+2+4+8 etc., taki =MathPow(2,i+1)-1;

It's clearer in the binary code.

uncleVic:

The misgivings are very reasonable. The above code only justifies the fact that the set of visibility flags is actually a macro.

The correct way is to work through it:

Same thing in principle. If you change in the list of af's, you'll have to edit the code.

I can't imagine any universal solution, and I suspect that it's theoretically impossible to foresee possible changes.

x100intraday:

Wrong again, though. Let me explain. In the example, static ENUM_TIMEFRAMES _p_int[] is created for 21 items, but here's what I want: I already have such an array, but it can be of any length. It is an array containing the timeframes, on which something will be built. But they should also be visible on all lower timeframes and none of the arrays is filled with them separately or additionally from the existing ones. So here I am mentioning the necessity to calculate flags of the current timeframe and all lower timeframes and sum them up in the regression loop on the fly, dancing from the current one. The trick is not to create a complete array of preset values of anything (even of timeframes or visibility flags) and loop through them, but to calculate in mind on every turn only the incomplete array of preset timeframes.

No, you won't. The correspondence of timeframe and visibility has to be defined. Or two corresponding arrays, or switch.

+array with those TFs you need, +init calculates object visibility for every TF you use. Something like this...)

[Serj]

I can't figure out what's wrong.

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

[Ilyas]

her.human:

I've racked my brains, I don't understand what's wrong?

It's an error in the compiler optimizer. Thank you for your message, we will fix it.

The error occurs with the following construction

if(VirtualSL==0.0 || (VirtualSL!=0.0 && stopcal>VirtualSL))
if(VirtualSL<stopcal)

VirtualSL!=0.0 can be removed from the second part of the first if condition,since this expression is always true after the first part is checked. The optimizer error will disappear.


Corrected, the fix will be included in the next build.