AssignAutoStopTargetPrices-explained

Thank you Glitch,

The answers to questions one, two, and three are what I hoped they would be.

Question number "4." referred to the scenario in which I was mainly thinking about how the execution price is retrieved within the time slot.
If one works with a scaling of N minutes, is the status (filled) and the execution price determined in between?

The video was helpful. I noticed that in my implementation only the AssignAutoStopTargetPrices() is used, but in the video the code additionally sets the limit prices for the transaction when they are placed. With the AssignAutoStopTargetPrices() method alone, no OCO order has been placed with the broker yet. Can you explain or confirm this?

Well, I add the limit price to the transactions so that I have both code elements as in the video and will watch what happens.

I would still appreciate a short feedback on point "4." and on the point why the method (apparently) alone is not sufficient (which is not a problem if it works together with the prices that are set when the order is placed).

Yesterday it worked for me by setting the transaction values additionaly to the AssignAutoStopTargetPrices() method.

CODE:

t = Place(...)
t.AutoStopLossPrice = X;
t.AutoProfitTargetPrice = Y;

The example in the QuickRef does not implement it and the backtest works when the AssignAutoStopTargetPrices() method is used exclusively. If you set the method and the values also the OCO order will be placed.

Thanks.

That's not required. AssignAutoStopTargetPrices() will just overwrite anything you do with the Transaction before that. In other words, you're assigning values to the same properties. You can do it twice if you want to, but AssignAutoStopTargetPrices() also gives you the opportunity to work with the live/actual execution price.

Okay, thanks Cone! For now, I'll use it the way it worked for me. So there must have been some other reason. If I notice something I can revisit the topic.

Hi.

When examining my backtest results, I also took a closer look at the exits for Take Profits with the same exit bar (AssignAutoStopTargetPrice). This raised the following question for me for trades entered with a limit order.

CODE:

      public override void AssignAutoStopTargetPrices(Transaction t, double basisPrice, double executionPrice)
      {
         t.AutoProfitTargetPrice = executionPrice * 1.03;
      }

I think you can't know if the exit price was there before or after the order was filled. The timing is only clear for the open and close price. My understanding is that if the limit is not hit when the bar opens (bars.Open <= limit price for a buy limit) you can not use the same bar exit.



You can see from the three examples that the limits were reached below the opening price of the bar (it has to move there). Although this is possible due to gaps or up and down scenarios (in the example of 3%), the more common case is that the price moves continuously towards the limit price (after touching the exit price). If the price does not recover, the exit would be wrong.

Finally we do not know if we are in a more common or in an exceptional (gaps and up/down scenario). As I understand it, this exit logic (AssignAutoStopTargetPrices) can only be applied when the opening price has reached the limit. This defines the timing and ensures that the exit price after the limit price is reached. Let's see what you think about it.

>>My understanding is that if the limit is not hit when the bar opens (bars.Open <= limit price for a buy limit) you can not use the same bar exit.<<

What makes you think that? It's just a regular limit or stop order. If the market does not take out the price at open, then maybe it will advance (or decline) to reach the limit/stop at some future time in the trading day and the order would execute then.

QUOTE:

What makes you think that? ...

My comment after the screenshot.

I read your comments but am not understanding your question or what you're not sure about. Let's take a simple example of a sell at profit target of $100.

If the stop opens up at $110 at open, then the order will get filled at open at $110.

If the stop opens at $95, but the HIGH of the bar is $120, then the limit order will get filled at the limit price of $100.

QUOTE:

If the market does not take out the price at open, then maybe it will advance (or decline) to reach the limit/stop at some future time in the trading day and the order would execute then.

Yes, it can be executed at a later date. But you need to know which price occurred first. The limit for entering the trade or the exit price. How do you know that the entry price will be reached before the exit price? The trade must be entered before you can use the exit. It is time dependent.

By the way, happy new year to the WL team.

MIH - I agree. You can't properly backtest same-bar limit and stop exits after a stop or limit entry. (Generally you do this only for market order entries.) The exception is when you know the order of the prices, like using a stop price below a buy at limit price.

OK, yes I was assuming the use of a market order to enter the trade. If you're also entering with a limit or stop then yes it's not 100% deterministic.

QUOTE:

... The exception is when you know the order of the prices, like using a stop price below a buy at limit price.

True. Which will be the case when the open <= (entry) limit price. If the time sequence is not known, a regular exit scenario "can" also occur.
It is then simply very optimistic measurement.

To control the level of optimism I tried the following idea yesterday. The values are only for illustration.
This can be applied for trades where the entry limit is below the opening price.

CODE:

      public override void AssignAutoStopTargetPrices(Transaction t, double basisPrice, double executionPrice)
      {
         // play with more code to apply it only to limit < open scenarios
         if (rnd.Next(0, 100) < 25)
         {
            t.AutoProfitTargetPrice = executionPrice * 1.03;
         }
      }

What i want to say is, that being aware of it, it can be handled in different ways.
My suggestion would be that the "default" setting should be the most pessimistic one. (e.g. in a long scenario bars.open <= buy limit)

How can I retrieve the index of the entry bar in AssignAutoStopTargetPrices() to access the relevant price information? I have only found t.EntryDate, do I need to go through the bar history? Can i use "GetCurrentIndex()" for this purpose?

CODE:

      public override void AssignAutoStopTargetPrices(Transaction t, double basisPrice, double executionPrice)
      {
         // how to retrieve the entry bar index
         double open = t.Bars.Open["IndexOfEntryBar"];
         
         if(open <= "WhichPriceToCheck")
         {
            t.AutoProfitTargetPrice = executionPrice * 1.03;
         }
      }
      

The placeholder "WhichPriceToCheck" is not clear to me. There is Orderprice, BasisPrice, ExecutionPrice and maybe more. Which price corresponds to the limit price, i guess the OrderPrice. I think the placeholder "IndexOfEntryBar" is self explaining.

Is the following solution correct (for a buy limit order) ?

CODE:

      public override void AssignAutoStopTargetPrices(Transaction t, double basisPrice, double executionPrice)
      {
         // how to retrieve the entry bar index
         double open = t.Bars.Open[GetCurrentIndex(t.Bars)];

         if(open <= t.OrderPrice)
         {
            t.AutoProfitTargetPrice = executionPrice * 1.03;
         }
      }

Looks correct to me.
For a limit order, basisPrice is equal to the t.OrderPrice, so you could use either one.

Edit -
I wasn't 100% sure if GetCurrentIndex() would return the index of the Signal or Trade bar - but it's the Trade bar, which is what we want here.

The same for me with the GetCurrentIndex(). Here is another tweek.

CODE:

      public override void AssignAutoStopTargetPrices(Transaction t, double basisPrice, double executionPrice)
      {
         // how to retrieve the entry bar index
         double open = t.Bars.Open[GetCurrentIndex(t.Bars)];

         if (t.OrderType == OrderType.Market || open <= t.OrderPrice)
         {
            t.AutoProfitTargetPrice = executionPrice * 1.03;
         }
      }

I am not sure what different cases need to be covered and what will ultimately remain optional. I guess that for long positions, market and standard limit orders can be handled with it. Of course, the logic for stop orders can also be implemented accordingly. I see no difference in the approach

QUOTE:

Edit -
I wasn't 100% sure if GetCurrentIndex() would return the index of the Signal or Trade bar - but it's the Trade bar, which is what we want here.

I asked myself how to access the signal bar index. It is useful to access dynamic data. In the given example i use atrp for illustration. I used the "Tag" property of the transaction object. I am not sure if it is the intended way. It looks like that.

CODE:

      public override void AssignAutoStopTargetPrices(Transaction t, double basisPrice, double executionPrice)
      {
         // indices of signal and trading bar
         // "t.tag" must be set when the trade is placed
         int tradingBarId = GetCurrentIndex(t.Bars);
         int signalBarId = (int)t.Tag;
            
         // open price is used to control exit logic
         double open = t.Bars.Open[tradingBarId];

         // e.g: take profit with "dynamic" price level
         if (t.OrderType == OrderType.Market || open <= t.OrderPrice)
            t.AutoProfitTargetPrice = executionPrice * (1.0 + atrp[signalBarId] / 100);

         // e.g.: stop loss with fixed price level
         if(t.OrderType == OrderType.Market ||  open >= t.OrderPrice)
            t.AutoStopLossPrice = executionPrice * 0.9;
      }

Setting the index when placing the trade. Of course, operations relative to the SignalBar or Trading Bar are also possible in this way.

CODE:

            if (!HasOpenPosition(bars, PositionType.Long))
            {            
            Transaction t = PlaceTrade(bars, TransactionType.Buy, OrderType.Market, 0, -1, "Buy At Close");
            t.Tag = idx; // used with sameBarAutoExits()
            }

>>OK, yes I was assuming the use of a market order to enter the trade. If you're also entering with a limit or stop then yes it's not 100% deterministic.<<

We are improving the simulation of same-bar exits for Build 32. If the entry order is not a market order, the same-bar exit price will need to be reached on a CLOSING price basis in order for the same-bar exit to fill.

In the future we can bring granular processing into the picture too, but for now this eliminates inflated backtest results where same-bar exits are used in conjunction with non-market order entries.

>5) These exits are alive only during the entry bar.
So there is no way for sl and tp to always be set on the broker side as a gtc bracket order? And what to do if such a possibility is needed?

QUOTE:
So there is no way for sl and tp to always be set on the broker side as a gtc bracket order?

No. WL8 does not support GTC orders. Strategies generate signals for each bar.

QUOTE:
And what to do if such a possibility is needed?

Rework your strategy to conform with non-GTC orders.

>Rework your strategy to conform with non-GTC orders.
It's impossible on forex, moreover, it is a basic thing in algotrading that the sl is always on the side of the broker, because the application can hang up or the connection is interrupted

It's always on the side of the broker, your strategy just continues to submit it every bar.

By always I mean even if connection to broker is lost. With the current implementation the day order expires and we'll have a problem. This is important in crypto and forex. Is there a reason why GTC is not implemented?

Yes, for the sake of simplicity though you can try to change your stop order to GTC in your trading platform.