Hi,

Such a message generally is an indication that the PRT parser chokes on conditional stuff inside your code, which it tries to be intelligent about (predict what variables are going to be used downstream so they don’t need to be explicitly defined by you, the coder). Generally you can’t help it going wrong, as in all cases I run into it, it’s just a PRT bug. Easy example :

GraphOn = 1        // Debug Mode. 

If GraphOn then    // Debug Mode ? 
  Graph OnMarket   // 0 or 1
endif

This may go wrong depending on unknown internal situations, and the solution is to remove (comment out) that If GraphOn and adjacent Endif.

In your situation the For loop including the Sell and ExitShort commands, look sufficiently suspicious to me to avoid. So notice that your conditions would allow to trigger several of either, and the choking is on. You could cover for this technically wrong setup by means of tracking that one of the commands has been executed already (thus, formally you will be off market in the next call of the bar/code) so you won’t execute a next which would overrule the previous. In your case you’re thus not only overruling a former Sell with a Sell, but you will also overrule a former Sell with an ExitShort. And vise versa.

Try it out quickly by means of looping one time only (not 7 times (0 to 6)) and comment out the ExitShort (or Sell).

Heads up, because what you do seems nice. 🙂
Peter

IF $priceMem[x] = 1 AND NOT LongOnMarket THEN
  IF close CROSSES OVER $priceLimHigh[x] THEN
    $priceMem[x] = -1
  ENDIF
ENDIF

Maye you can concentrate on the part above;
So you’re inside of an If conditioned by an array variable which you set within that If ( $PriceMem[x] ).

Normally this can be done of course, but arrays could be too much of a tweak for PRT itself to have thought of this situation.

priceMemHlp = $priceMem[x]

IF $priceMem[x] = 1 AND NOT LongOnMarket THEN
  IF close CROSSES OVER $priceLimHigh[x] THEN
    priceMemHlp = -1
  ENDIF
ENDIF

$priceMem[x] = priceMemHlp

Untested of course so I hope I have the logic right.

Because this is so often about “structures”, also think of this setup which is more common to PRT coding/coders :

Condition1 = close CROSSES OVER $priceLimHigh[x]
...

If Condition1 then 
  ...

I wouldn’t do it like that by nature, but still it is a means, and it avoids more “structure” as such for the “parser”.

Do you receive the error during Optimization (iterating over Optimization Variables) ? or do you receive the error when the backtest tries to show the Stats of the result ?
When you don’t recognize “Optimization” as such, you would not be able to tell, unless without the error the result is there 50 times faster. I hope this is clear ?
Just in case it is new to you, Optimization makes use of the form with at the bottom of it what you see below.

It’s not possible to use CROSSES OVER/UNDER with arrays as they are NOT historicized, i.e. $myElement[N]  will only retain the current value, as it’s not possible to access the value retained the prior candle. Whenever you change it, the previous value is lost.

CROSSES means comparing the previous valus with the current one. Since only the current one is available, those instructions cannot be used. If you know what element is to be compared, I suggest to assign its value to a variable,  provided you know what element of the array is the one to be tested:

 .
 .
 IF close CROSSES OVER MyVariable THEN
    .
 ENDIF
 .
 . 
myVariable = $myElement[5]

this will work, as I only want to test element 1:

IF BarIndex = 0 THEN
   $myArray[1] = 0
   $myArray[2] = 0
   $myArray[3] = 0
ENDIF
IF OnMarket THEN
   SELL AT Market
ENDIF
$myArray[1] = $myArray[2]
$myArray[2] = $myArray[3]
$myArray[3] = close
x = $myArray[1]
Sma = average[20,0](close)
//IF $myArray[1] CROSSES OVER Sma THEN    // ERROR
IF x CROSSES OVER Sma THEN
   BUY AT Market
ENDIF