Norgate's padding
Norgate adds only the "closing price" to populate the bar thus fooling Amibroker in delaying the re-calculations until Wednesday being the first trading day since the trading halt. Amibroker requires an "opening price" in the data for its re-calculation. It would be preferable to miss the buy altogether or allow the user to delete that position. With (ASX:IPD) still in the portfolio (using either method) another position can't be substituted until a sell signal for that position is generated.
In my previous message I wasn't connecting the dots since I had a bias for how I code my rotational strategies.
I use daily periodicity, whether my rotational strategy is weekly or monthly, then some fiddling with the PositionScore to get it to work.
Some code excerpts:
//
https://forum.amibroker.com/t/simple-buy-certain-day-and-sell-few-days-later/16621/3 and
//
https://forum.amibroker.com/t/how-to-identify-and-define-trading-days/23630/3?u=linusvanpelt
// "Your condition is True only on bars where the current bar's Month is not equal to the most recent previous bar's Month,
// i.e. in daily data this will be the FIRST trading day of the month. And it will ONLY be true on that bar.
IsEOW=Nz(TimeFrameExpand(1,
inWeekly,
expandPoint));
IsFOW=DayOfWeek() < Ref(DayOfWeek(),-1);
IsEOM=Nz(TimeFrameExpand(1,
inMonthly,
expandPoint));
IsFOM=Month() != Ref(Month(),-1);
...
score = IIf(IndexExit==1,
scoreExitAll,
IIf(IsEOW==0,
scoreNoRotate,
IIf(OnSecondLastBarOfDelistedSecurity
,0,myrank*LiquidityFilter)));
PositionScore = score;
So, something to try...
* Change to daily periodicity in Analysis settings
* Use time compression for your system rules. Once you wrap your head around this (it took me a while) and you have some boilerplate code it's not hard.
* Use IsEOW as a condition for buy (i.e. a positive PositionScore)
* Trap for the padded bar on the buy day itself, something like Iif(V==0 OR NorgatePaddedTimeSeries != 0,0, IIf(OnSecondLastBar,...)
* Perhaps SetTradeDelays=0 and build the trade delay via your AFL? I've seen you code this before.
* Would Ref(1) be a future leak here? Usually it would be, but the fact is that, if the bar was padded (not traded) the code would match the actual trading - you could not have bought the symbol that day. Perhaps your backtest is in fact detecting something you wouldn't know - that it didn't trade on Monday - but the end result in live trading is the trade would have been rejected by the exchange. You would of course really want to test this thoroughly so that it didn't cause a future leak or other issues - the effect of Ref(1) would need to be limited to this very specific issue only.
I'm just lobbing this out there - I haven't tested this, nor do I have time to mock up something to test this scenario.
The gist of this is, if you're using Weekly periodicity, your IPD.au bar will collapse to a weekly bar, and you'll lose the granularity of data needed to detect that the symbol did not trade on Monday or Tuesday. This was what I missed in my first post (and perhaps other things).
You need code that will:
Generate a weekly signal;
But override that signal on the buy day if the bar was padded. You may just need to check the buy day only, i.e. Monday. I wouldn't buy on Weds, but rather check if the symbol met the system rules the following week. So any days other than EOW and FOW would be scoreNoRotate days as far as the backtest is concerned.
I'm sure you know this already, but for those who don't (and I have to continually reference this page myself), this is a good page to bookmark:
Read the various scenarios under Rotational Trading. Scenario 3 might be helpful.
Then there's always the CBT, although TBH I don't know how it works with Rotational systems. You probably have to do all the work in the CBT that you get for free with backtestRotational. I think it should be possible with StaticVarGenerateRanks, where you pre-derive each symbol's weekly rank in a Status("stocknum")==0 block, then pass that to the CBT to do the Phase 2 processing and execute the equivalent of your rotational strategy.
Hope some of this was useful
P.S.: I have a monthly rotational strategy that is not coded with backtestRotational, but is actually a "roll your own" rotational strategy with both buy and sell on EOM. I tried both backtestRotational and this approach, and this approach got better returns. My analysis is it gives the strategy a chance to rebalance each month, taking larger (or smaller) position sizes each month depending on current equity. I doubt this would be the case with a weekly strategy, with lower expectancy and higher commission costs. But I believe it would be easier to code this scenario, since you have separate Buy and Sell variables instead of it all wrapped up in PositionScore.
I'm sure Tomasz could have coded Rotational strategies in many ways - he chose the most obtuse