Using "Switch" versus multiple "if's"...any preference to be given one over the other? - page 3

New comment
 

I don't follow, with switch you have the choice of using break to exit or opt to not use break and allow the cascading switch conditions execute as well. What exactly would you like an example of? a nested switch? (not a facetious question, I will be happy to provide but want to make sure I am answering the right question)

 
1005phillip:

I don't follow, with switch you have the choice of using break to exit or opt to not use break and allow the cascading switch conditions execute as well. What exactly would you like an example of? a nested switch? (not a facetious question, I will be happy to provide but want to make sure I am answering the right question)

"...flexibility and extra control...", I thought you have some other tricks to abuse Switch. An elaborate nested Switch would be great.

Below is my recent use of Switch that on my attempt can't do without If. Perhaps you have an alternative view/s. 

int P = Period(); 

if( P > 0  && P <= 15 ){ TF_Level = 1 }
if( P > 15 && P <= 60 ) { TF_Level = 2 }
if( P > 60 && P <= 240 ) { TF_Level = 3 }
if( P > 240 && P <= 1440 ) { TF_Level = 4 }
if( P > 1440 && P <= 10080 ) { TF_Level = 5 }
if( P > 10080 && P <= 43200 ) { TF_Level = 6 }

Switch( TF_Level )
{
case 1 : ( do stuff } break; 
case 2 : ( do other stuff } break; 
case 3 : ( do other stuff } break; 
case 4 : ( do other stuff } break; 
case 5 : ( do other stuff } break; 
default : ( do other stuff } break; 
}
 

Ah, I see what you are speaking to now. Yes switch is only useful for those cases where the evaluated expression holds explicity bounded values.

Now in your specific example, the use of Period() is an explicitly bounded parameter unless you have created your own timeframe (which you could then hardcode just as well into the switch).

So I'd look to implement the following:

switch(Period())
   {
   case 1      :  // fall thru to next case
   case 5      :  // fall thru to next case
   case 15     :  TF_Level = 1; (do stuff); break;
   case 30     :  // fall thru to next case
   case 60     :  TF_Level = 2; (do stuff); break;
   case 240    :  TF_Level = 3; (do stuff); break;
   case 1440   :  TF_Level = 4; (do stuff); break;
   case 10080  :  TF_Level = 5; (do stuff); break;
   case 43200  :  TF_Level = 6; (do stuff); break;
   default     : Print("zomg like stuff didnt happen yo"); break;
   }

and here is an example of nested switching:

switch(OrderType())  // was the order a buy or sell order?
   {
   case OP_BUY    :  switch(CalculatedSymbolType) // Determine the tickvalue for the financial instrument based on the instrument's SymbolType (major, cross, etc)
                        {
                        case 1   :  (do stuff); break;
                        case 2   :  (do stuff); break;
                        case 3   :  (do stuff); break;
                        default  :  Print("Error encountered in the SWITCH routine for calculating MAE");
                        }
                     MFEBar=HighestBar; break;

   case OP_SELL   :  switch(CalculatedSymbolType) // Determine the tickvalue for the financial instrument based on the instrument's SymbolType (major, cross, etc)
                        {
                        case 1   :  (do stuff); break;
                        case 2   :  (do stuff); break;
                        case 3   :  (do stuff); break;
                        default  :  Print("Error encountered in the SWITCH routine for calculating MAE");
                        }
                     MFEBar=LowestBar; break;

   default        :  Print("Error encountered in the SWITCH routine for calculating OrderType");
   }
 
cameofx:

Below is my recent use of Switch that on my attempt can't do without If. Perhaps you have an alternative view/s.

Just one comment - you realize that using IF-ELSE's would likely be much faster... Plus, depending on the expected possible values, the last 'IF' statement is redundant if done like so:

int P = Period(); 

if( P > 0  && P <= 15 ){ TF_Level = 1 }
else if( P > 15 && P <= 60 ) { TF_Level = 2 }
else if( P > 60 && P <= 240 ) { TF_Level = 3 }
else if( P > 240 && P <= 1440 ) { TF_Level = 4 }
else if( P > 1440 && P <= 10080 ) { TF_Level = 5 }
else /* if( P > 10080 && P <= 43200 ) */ { TF_Level = 6 }     //quoting out the 'if' part depends on the expected possible values...

//...
 

1005phillip wrote >> Ah, I see what you are speaking to now. Yes switch is only useful for those cases where the evaluated expression holds explicity bounded values.

Now in your specific example, the use of Period() is an explicitly bounded parameter unless you have created your own timeframe (which you could then hardcode just as well into the switch).

So I'd look to implement the following:

and here is an example of nested switching:

  1. I'm thinking more like it is because switch is restricted to testing only 1(the lonely quantity of uno) parameter and it have to be a constant (yet another restriction, an immovable, unchangeable, non-variable, need I mention the adjective constant, entity) or function that return constant. Its uses are limited, it's not meant to test condition/s but rather inspect result of 1-single parameter. If used as it's meant to be used, then Switch reign superior.

  2. I'm playing around with my imaginary version of Switch which I think ended up to something like Class isn't it (or not) or a grouped If ? :))))))
    Switch ( int expression_operation_Parameter_1 ;
double expression_operation_Parameter_2 ;
int type ;
bool checkPeriod(10080) ;
xxxx expression_operation_Parameter_n ;
)
{
case ( result_testParameter_1 + n ==2 ; result_testParameter_2 > x ; OP_BUY ; true ; xxxx ) : { do stuff ; }
case ( result_testParameter_1 + n >=3 ; result_testParameter_2 < x ; OP_SELL ; true ; xxxx ) : { do stuff ; }
case ( result_testParameter_1 + n ==y ; result_testParameter_2 >= x ; OP_SELLSTOP ; false ; xxxx ) : { do stuff ; }
case ( result_testParameter_1 + n ==z ; result_testParameter_2 > x ; OP_BUYSTOP ; true ; xxxx ) : { do stuff ; }
case ( result_testParameter_1 + n <=2 ; result_testParameter_2 == x ; OP_BUYLIMIT ; true ; xxxx ) : { do stuff ; }
}
  3. Your implementation of Switch on my function is close but did not fulfill the aim, which is deciding an interval of period(), It's meant to be used also in 'odd' chart period (produced by Period_converter) and/or
    new 21 standard Mql5 periods.
  4. Thank you for the example, Phillip....
 

yeah I would implement if/else-if like gordon's example in your situation, the idea isn't to contort every situation into becomming switch-friendly, switch can help keep some code clean and easier to manipulate but nested if/else-if's are certainly a far more general approach imo.

 
gordon:

Just one comment - you realize that using IF-ELSE's would likely be much faster... Plus, depending on the expected possible values, the last 'IF' statement is redundant if done like so:

  1. I do realize that. I use IF - ELSE IF - ELSE combination all over my codes (using this combo would make it more like Switch, btw, minus the annoying break).
  2. Oddly, I weigh if it's worth typing also in selecting operator method, I try to be concise, by that I prefer not to see that extra else on said particular situation.
  3. It was only accessed once in init so why crowd the code. It will not affect speed noticeably, even with my Celeron PC 256mb RAM :)).
1005phillip:

yeah I would implement if/else-if like gordon's example in your situation, the idea isn't to contort every situation into becomming switch-friendly, switch can help keep some code clean and easier to manipulate but nested if/else-if's are certainly a far more general approach imo.

  1. Phillip, please read my reply to Gordon point no.1.
  2. Also previous post, point no.1 regarding my opinion of switch
  3. "...Isn't to contort every situation into becomming switch-friendly" That is not the case regarding my chosen if-if-if... combined with Switch method. The funny thing is, I was only resorted interested in attempting to try using Switch on that particular situation after reading your thread :).
  4. And your implementation proves my point; you can't achieve my aim (read point no.3) solely with Switch, as I can't.

best regards
cameo

123
New comment
Reason: