Hello,

at the moment I backtest my system and try to find an appropriate exit strategy.

I use ACSIL Programming Concepts and have Tick Data available.
After a backtest I check the results using Trade Activity Log, especially columns Profit/Loss, Runup, Drawdown.

I can see that there are sometimes huge price gaps between the price that fulfills my exit condition and the price shown in the trade log. This makes it impossible to test and optimize exit strategies like trailing stops for me.

Example:
I use a trailing stop of 100$ based on the Runup in the code, e.g. stop = runup - $100.
Even if the position is in profit with runups way beyond $100, I see losses in the P&L row after the backtest
that are beyond any tolerance bands acceptable or slippage.

It seems that the price in the log is always the close price of the bar after the exit condition was fulfilled.
Of course if this is a huge bar the price can be way away from my exit condition.


I use Auto Trade System Bar Based Backtest for this because it is relatively fast.

If I use Auto Trade System Replay Backtest it is extremly slow and also the values recorded in Trade Activity Log seem to be wrong, e.g. in Runup column I see huge runups that do not correspond with the charts and are not identical with the runups when I used Bar Based Backtest, e.g. Bar Based Runup = $ 300, Replay Runup = $ 3995
for the same trade.


Another issue I had with Sierra Chart while backtesting was regarding to the position sizing.

I use an algo to determine position size depending on my risk per trade and the following code:

NewOrder.OrderQuantity = Quantity;

Quantity is a variable filled by the algo mentioned above, e.g. 3 contracts.

When I have quantities > 1 I can see partial order fills while backtests in the trade log when my exit conditions are met, e.g. 3 fills at the same time.

Since my code does not use any scaling out methods and since I always exit on the full position size this is very strange (no help from support).

Maybe someone of the forum users can give me an advice if it makes sense to proceed with Sierra Chart
in general for serious trading systems development.


Default section:

sc.StudyDescription = "This study function is a Testenvironment";
sc.AutoLoop = 1;
sc.GraphRegion = 0;
sc.FreeDLL = 1;
sc.AllowMultipleEntriesInSameDirection = false;
sc.MaximumPositionAllowed = 100000;
sc.SupportReversals = false;
sc.SendOrdersToTradeService = false;
sc.AllowOppositeEntryWithOpposingPositionOrOrders = false;
sc.SupportAttachedOrdersForTrading = false;
sc.CancelAllOrdersOnEntriesAndReversals = true;
sc.AllowEntryWithWorkingOrders = false;
sc.CancelAllWorkingOrdersOnExit = false;
sc.AllowOnlyOneTradePerBar = true;
sc.MaintainTradeStatisticsAndTradesData = true;


Statement

if (sc.GetBarHasClosedStatus() == BHCS_BAR_HAS_NOT_CLOSED) return;

is disabled !


Looking forward to any comments or suggestions.

Regards,

Chris

> if (sc.GetBarHasClosedStatus() == BHCS_BAR_HAS_NOT_CLOSED) return;
> is disabled !

Yikes! If I disable this, then I get fills from the previous bar instead of the bar after my indicator fires.

chris123 

I can see that there are sometimes huge price gaps between the price that fulfills my exit condition and the price shown in the trade log. This makes it impossible to test and optimize exit strategies like trailing stops for me. .... It seems that the price in the log is always the close price of the bar after the exit condition was fulfilled. Of course if this is a huge bar the price can be way away from my exit condition. .... I use Auto Trade System Bar Based Backtest for this because it is relatively fast. Chris

It sounds like you shouldn't use the bar-based backtest if you need trades to execute mid-bar. Not sure about the other issues. I hope you find a solution. I am getting used to backtesting in SC also.

This thread has a lot of views.

I think a lot of people must be looking for general SC backtesting info or something.

If there are any SC vets here that use the platform for automation or have extensive backtesting experience with it I would be interested in talking to you.

I have worked with the bar based backtest in Sierra for a couple of weeks and I’ve convinced myself that it can be wildly inaccurate. The tick by tick replay is supposed to be much more accurate, but I’m still trying to figure out how to make it run consistently.

Happy to collaborate on this, LittleFinger.

Anyone with a similar interest is free to message me.


Sent using the NexusFi mobile app

bbking 

I have worked with the bar based backtest in Sierra for a couple of weeks and I’ve convinced myself that it can be wildly inaccurate. The tick by tick replay is supposed to be much more accurate, but I’m still trying to figure out how to make it run consistently. Happy to collaborate on this, LittleFinger. Anyone with a similar interest is free to message me. Sent using the NexusFi mobile app

I'm glad you brought that up. It is unfortunate the way that the bar-based backtest calculates to distort your results to make them look much better.

From what I've seen, if your exit rules can calculate mid bar, then absolutely do not use the bar-based backtest. It will determine the absolute best price to get you out of the trade, even if it was impossible for you to be filled at that price. It will dramatically inflate the results of any backtest that does mid-bar calculations for entry or exit.

However, if you add sc.GetBarHasClosedStatus() == BHCS_BAR_HAS_CLOSED to your exit logic then you can get close results on the bar based backtest to what you get on a replay test, but there will be some imperfections.

LittleFinger 

if you add sc.GetBarHasClosedStatus() == BHCS_BAR_HAS_CLOSED to your exit logic then you can get close results

This is an important point to reiterate for anyone else. Setting sc.GetBarHasClosedStatus() == BHCS_BAR_HAS_CLOSED was absolutely critical to prevent the awarding of prices from the before the open point of the bar.

Even so, I found that the "logic" (which is documented) is not really what I want, from the bar based testing. I asked Sierra to give users the ability to control how fills are made, but they have so far studiously avoided even responding to the request.

If you or anyone else would like to be able to control exactly how fills are awarded in your bar backtest, please add a comment in support here:

https://www.sierrachart.com/SupportBoard.php?ThreadID=41741

I agree that some options on the bar based logic would be nice.


I'm currently trying to figure out the best method to limit a strategy to one trade a day.


I was thinking compare current day with day of last fill, but not sure how to get the current day on the chart for backtesting and not actual current day.

LittleFinger 

I'm currently trying to figure out the best method to limit a strategy to one trade a day. I was thinking compare current day with day of last fill, but not sure how to get the current day on the chart for backtesting and not actual current day.

a) How to get the start time of the most recent bar, in an ASCIL study; so here I log the bar time:

 

Code

// define a macro to make it easy to do very verbose logging. #define vv(args...) \ do {SCString Msg; Msg.Format(args); sc.AddMessageToLog(Msg, 0);} while(0); int BarStartTime = sc.BaseDateTimeIn.TimeAt(sc.Index); int minuteOfDay = BarStartTime / 60; int sec = BarStartTime % 60; double close = sc.Close[sc.Index]; vv("at simtm %02i:%02i:%02i at sc.Index %i, close=%f", minuteOfDay / 60, minuteOfDay % 60, sec, sc.Index, close)

b) To process each bar once (advice from the Sierra documentation); could be generalized...

 

Code

if(sc.GetBarHasClosedStatus(sc.Index) != BHCS_BAR_HAS_CLOSED) { return; } //This demonstrates a simple method to prevent processing on a bar more than once. //All bars in the chart other than the last one are only going to have processing for\ them in a study function, done only once. //However, the last bar in the chart could be multiple times during real-time updatin\ g and during a chart replay. // // must come *after* the BHCS_BAR_HAS_CLOSED check! // int &LastBarIndexProcessed = sc.GetPersistentInt(1); if (sc.Index == 0) { LastBarIndexProcessed = -1; } if(sc.Index == LastBarIndexProcessed) { return; } LastBarIndexProcessed = sc.Index; // Here, I think if you now reference a static (file scope or global) variable that holds the // time of the last trade, you should be able to limit the trading to once per day.

I'm getting my feet wet still with programming so I'm going to have to work through your example slowly.

Thanks for that