abnormal behavior of if… and ..and ..and condition

• 02/25/2019 at 5:47 PM #92284
  waid

  Let’s say

  buyCondition = average[10] crosses over average[30] if A and B and C and buyCondition then ... endif

  1 2 3 4

  buyCondition = average[10] crosses over average[30] if A and B and C and buyCondition then     ... endif

  the result will be totally different from:

  if buyCondition and A and B and C then ... endif

  1 2 3

  if buyCondition and A and B and C then     ... endif

  I found this abnormal behavior when I do my experiment on Nicolas’s nice post (This abnormal behavior is nothing to do with the code of Nicolas’s post. I show the post here is just to give a code base for a quick experiment):

  https://www.prorealcode.com/blog/learning/how-to-improve-a-strategy-with-simulated-trades-1

  First, you can change the code block (at # line: 22):

  elsif not realtrading and ordercount>equityCurvePeriod then //fake trading if not longontrading and buysignal then

  1 2	elsif  not realtrading and ordercount>equityCurvePeriod then //fake trading if not longontrading and buysignal then

  into:

  elsif buysignal and not realtrading and ordercount>equityCurvePeriod then //fake trading if not longontrading then

  1 2	elsif  buysignal and not realtrading and ordercount>equityCurvePeriod then //fake trading     if not longontrading  then

  or

  elsif buysignal and not realtrading then //fake trading if ordercount>equityCurvePeriod and not longontrading then

  1 2	elsif  buysignal and not realtrading  then //fake trading     if ordercount>equityCurvePeriod and not longontrading  then

   

  and run both. You can easily see the difference.

   

  note that logic of code blocks is equivalent to:

  elsif buysignal and not realtrading and ordercount>equityCurvePeriod and not longontrading then

  1	elsif buysignal and not realtrading and ordercount>equityCurvePeriod and not longontrading then

  You may switch each position of those conditions around. (and see the abnormal when buysignal is in 1st or 2nd position)

   

  I don’t know whether such abnormal is due to PRT’s intrinsic bug or maybe there is a basic rule for if… condition that I don’t know yet.

   

  Does someone know the cause? And how to avoid such unpredictable behavior?

   

  ps. also there is a bug in backtesting when running for i=0 to aNumberLargerThan500, the “i” will never exceed 500. Everyone can reproduce it by putting this code into backtesting :

  for i=0 to 999 do cantBiggerThan500 = i next graph cantBiggerThan500

  1 2 3 4

  for i=0 to 999 do     cantBiggerThan500 = i next graph cantBiggerThan500

  Is this bug will be fixed on next PRT version?

   

  Thanks!

   

  

  waid

  Participant

  Topics: 5

  Replies: 8

  Been thanked: 0 times
  02/25/2019 at 6:16 PM #92286
  Nicolas

  Hi waid, thanks for the feedback about this issue. I moved your topic in the ProOrder forum since it is related to coding. I have no time now, but I will look deeper into your explanation by tomorrow.

  

  Nicolas

  Keymaster

  Topics: 81

  Replies: 20828

  Been thanked: 4738 times
• Author
  Posts