Trend-following / absolute momentum portfolio, consisting out of several futures
generate state signal buy, which will remain "buy" unless "sell" is triggered (via flip function)
Some example case:
portfolio risk is allocated, no more buy signals are taken (lack of funds, max risk etc.)
in the meantime, some more symbols flip to buy or are still in buy, however not taken (lack of funds, etc.)
one position exits, funds are available
which one is "best" to take (via my PositionScore / ranking)?
With BacktestRegular, this can't be simulated as redundant signals are removed.
With futures (different point values etc) I would like to implement a simple max loss stop, i.e. 3*ATR(20). As the stop is point based, I get the above error. Now, there is nothing wrong with the error per se, it's in fact implemented in such a way.
I'm looking for a workaround to implement point-based stops in BacktestRegularRaw, and if anyone has played with it already, maybe someone can shed light on why it was implemented (Error 43) this way because I currently don't understand it.
Just to add some more thoughts:
I can pass the 3*ATR(20) to CBT via a static variable and use Openpos.GetPrice to set the fixed stop when the position is actually entered. However, the exit cannot be implemented during the 1st backtester phase, meaning I would need to call ExitTrade from low-level backtest. I'm not sure if my explanation is clear, but it would mean I need to use low-level backtester.
The baseline is I don't know the exact entry in advance working on SIGNAL level, only in the second phase of the backtest can I implement my initial stop because then I know my entry.
So it is not about percent and point modes but it is about amount argument not being accepted to be array in backtestRegularRaw and rotational BT. So you would get error in bothstopModePoint as well as stopModePercent etc. if third argument of ApplysStop is type array (-> variable stop).
You have to ask developer for exact reason.
Other than that you may write custom stop via loop.
I get the idea that in BacktestRegularRaw the 3rd argument of Applystop has to be anumber, not an array.
When you say
Sure, but I can't do that on a symbol level because I don't know the exact entry which will be determined in the 2nd phase of the backtest only.
Pls I stand corrected, but other than a low level implementation, I don't see another way, do you?
Thanks for your consideration, but your link is not the solution for BacktestRegularRAW.
It's the solution for BacktestRegular instead.
sry, but the code in the library does NOT help in this case, because I do not know the exact entry in the 1st phase of the backtest.
Also as explained, BacktestRegular does not have the desired behavior for my scenario.
Is there a reason why the RAW mode is not compatible with variable stops?
I'm asking because I do not want to re-invent the wheel. Currently I will need to implement low-level CBT to use a variable stop-loss for BacktestRegularRaw.
You answered your question yourself - bar-by-bar changing amount is not available in backtestRegularRaw for the reason you just wrote - you don't know the exact entry and you can't process stops in first phase. Second phase uses fixed amount simply because you would run out of memory in many cases if you passed stop amounts for ALL symbols and ALL bars and ALL stop types (unless cases when you run on very small baskets, but AmIBroker is not for small baskets, AmIBroker runs tests on whole market which often exceeds 50000 symbols). Now if you run 50K symbol basket, 1M data points, 5 stop types, 4 bytes per float you would need 1000 GB of RAM just to store "stop amount".
I have tried using the number '5' as an "amount" for both Percent and Point based stops in rotational mode - both of them produce output which is not consistent in either percentage or point amounts in the backtest results.
Is there a way to use stops consistenyl in backtestRotational which works or are accurate stops just basically not available at all for rotational backtests meaning the only way to really use stops effectively is in backtestRegular - i.e. rotational systems with stops, targets or both cannot use backtestRotational mode?