Preventing impossible trades in backtesting

I have some strategies that frequently trade on the same bar. Most of these trades are fine, but in back-testing, I have reason to believe that some small number of them are trading in an impossible order. For instance, in a long trade, the price might enter the bar at an intermediate value, fall to the low that meets my sell condition, rise to a high that meets my buy condition, and then exit to the next bar. In back-testing, this would show up as a completed trade, since both my sell and my buy condition are met within the bar. Is there a way of ruling out such impossible trades when back-testing?

At first I thought that the HiLo1 function solved the problem, but it will reject single-bar trades even where the trade can be completed. For example, in the trade described above, if the price rises from the low to the high that triggers a buy, and then falls back down to the low that triggers the sale, conditioning the sale on high before low with HiLo1 would block the sale.

Is there a way to insist that sales come after buys on within-bar long positions, or before them on within-bad long positions?

Comments

  • No there is not a way - your profit and stops are too tight. CQG always takes the stance that the stop gets hit first - hence a negative return on a bar that has both limit and stop executing. TradeStation on the other hand will always take the profit objective over the stop on the same bar - talk about suger coating.

    There is not a way to know the historical developement of a bar within our code.

    CQG's backtesting can enter - exit on the same bar... it cannot enter - exit - reenter in a buy formula. It can sell - exit - buy within the same bar. That is the extent - our product was not made for scalping (executing many times within the developemet of the bar).
  • I think I may have been unclear, or perhaps I misunderstand your response. My second example is not about trying to get multiple trades in one bar. Instead, I was talking about the HiLo1 function, which, according to the documentation, "displays a 1 if the high for the bar occurred before the low, a –1 if the low occurred prior to the high and a 0 if less than 2 ticks have occurred." If this function performs as described, it lets you rule out impossible trades within a bar, by making sure that the buy condition occurs before the sell condition for a long position, or the sell before the buy for a short. I think it does do that, yes? For instance on a long transaction, adding AND HiLo1(@) < 0 to your buy condition will rule out impossible trades where the high occurs first within the bar.

    But this function is a little too aggressive in what it excludes when used in this way. If, within a bar, on a long trade, the price hits the sell condition, then the buy condition, then the sell condition again (and this happens often with a .75 renko brick on a quarter-point security), excluding bricks where the high appears before the low with the code above will block the trade, even though there is also a high that occurs after the low which makes the trade possible. So, for example, if instead of testing whether the high or low comes first, measured from the start of the bar, this function or some other function tested whether the high or the low comes last, measured from the end of the bar, then the function would give the right answer as to the possibility of the trade, regardless of the order in which buy and sell signals occur, or the price bounces up and down..

    And, while I am too new to be sure of this, or much of anything, truth be told, it seems to me that the order of at least some kinds of events in a bar could be determined by comparing the values of two instances of the SecSinceBarOp function, as applied to any conditions that it accepts. I am still pretty fuzzy on what sorts of conditions can be used to trigger time measurement functions like this one. Also, I think the crossing functions, XABOVE and XBELOW, can single out some price/time events within a bar and determine their order. Yes?
  • And I never mention a stop, and none of my examples included one.
Sign In or Register to comment.