I give you a quick example that can help. If you want to rebalance at month-end you can code it as below
PositionScore = IIf(Month() != Ref(Month(), 1), myConditions, scoreNoRotate); When using Rotational mode it will check the ranking - positionscore - on the last day of every month. The point is that some of your securities may have not been trading on that particular day and your ranking wouldn't be properly calculated causing erroneous rotation. Regular Backtest on the other side is working because doesn't require comparing the ranking on the very same day accross all securities but you can calculate the ranking at month end FOR EACH SECURITY no matter which was the very last trading day for each of them. For instance using: CorrectPosition = ValueWhen(Month() != Ref(Month(), 1), myConditions); and use it for proper buy/sell rules. I hope it make it clearer. Paolo --- In [email protected], "re_rowland" <rowl...@...> wrote: > > > If you have data holes, then I don't see how not using rotational mode fixes > your problem. Perhaps I don't understand your problem because I'm not sure > what you mean by "month-end rebalancing signals are incorrectly interpolated." > > --- In [email protected], "Paolo" <pcavatore@> wrote: > > > > Just wondering if anyone has ever noticed that backtestRotational doesn't > > work properly when dealing with data holes. > > > > These are quite frequent for instance at month-end across different > > international asset classes. > > > > Using the "Pad and align to reference symbol" doesn't always fix it > > properly since month-end rebalancing signals are incorrectly interpolated. > > > > This is just the last issue I've had with backtestRotational. My general > > experience is that backtestRotational is theoretically very useful but I > > often have to go back to code it using regular Backtest to make it work the > > way I need. > > In this case month-end signals are correct no matter of data holes. > > > > Just curious to know others' feedback. > > > > Paolo > > >
