With respect to SetTimeOfDayPriority - can it be extended to also select the right time-based exit in case both SellAtStop and SellAtLimit are in effect for a position?

Currently it seems if both the Stop and Limit prices are spanned on the same bar, the exit could be assigned somewhat randomly on either?

This issue amplifies as the time scale increases.

Is this a known issue? Without a similar time based priority logic as for limit entries, stop/limit exits seem to be totally unusable.

I know you guys are busy with issues with the latest release, but some response/direction would be appreciated.

QUOTE:
Is this a known issue? Without a similar time based priority logic as for limit entries, stop/limit exits seem to be totally unusable.

FAQ: I want to test a strategy that buys and sells with stop/limit orders on the same bar.

Appreciate your understanding that there exist topics more appropriate to discuss stop/limit orders per se. This one is dedicated to the C.Components priority methods.

QUOTE:
This one is dedicated to the C.Components priority methods.

But that's the point - I think the SetTimeOfDayPriority needs to be extended to deal with limit/stop exits in a similar fashion to limit entries.

FYI - I've looked at that FAQ, as well as the Wiki page http://www2.wealth-lab.com/WL5WIKI/LimitOrderPriority.ashx which leads us back to SetTimeOfDayPriority and hence this page and my request.

QUOTE:
With respect to SetTimeOfDayPriority - can it be extended to also select the right time-based exit in case both SellAtStop and SellAtLimit are in effect for a position?

I've read this a couple times and feel like I'm missing something. The whole purpose of SetTimeOfDayPriority is set a priority based on time of day for Stop and Limit orders - buy, sell, short, or cover - entry orders. The earlier the time, the higher the priority.

QUOTE:
Currently it seems if both the Stop and Limit prices are spanned on the same bar, the exit could be assigned somewhat randomly on either?

I'm assuming your indicating same "Daily" or higher scale. Again, this is the purpose of SetTimeOfDayPriority - to assign the priority based on the time of day.

Although you will run the strategy on Daily or higher scale, you must have intraday data for SetTimeOfDayPriority to work - even if it's hourly or 30-Min bars. If the stop/limit both get hit within the same intraday bar, well, the only way to get a more accurate time is to keep reducing the scale... down to the ticks (although I'm not certain that the method supports tick scales).

And note that your strategy code should test stops before limit exits so that in this case you get the most pessimistic results:

CODE:
Please log in to see this code.

Which data provider are you working with? Fidelity? IQFeed? other?

Hi Cone,

Thanks for the response.

QUOTE:
The whole purpose of SetTimeOfDayPriority is set a priority based on time of day for Stop and Limit orders - buy, sell, short, or cover. The earlier the time, the higher the priority.

It seems to only apply to the Entry part of the trade and not to Exits. So, it doesn't seem to apply to the SellAtLimit or SellAtStop orders which are exits. This seems to also be validated by your code above which uses p.EntryDate to compare against the Intraday date. There's no reference or comparison against p.ExitDate. Please correct me if this is not true.

QUOTE:
Although you will run the strategy on Daily or higher scale, you must have intraday data for SetTimeOfDayPriority to work

Yes, and I am using 5 min intraday bars.

QUOTE:
Which data provider are you working with?

Fidelity

Hi WLP123,

QUOTE:
It seems to only apply to the Entry part of the trade and not to Exits.

Exactly. Position.Priority in Wealth-Lab applies to entries exclusively. There's no such thing as "priority for exits".

Further reference: QuickRef tool > Position object > Priority.

QUOTE:
Exactly. Position.Priority in Wealth-Lab applies to entries exclusively.

I was responding to Cone's response about how it does apply to Sell and Cover signals.

QUOTE:
There's no such thing as "priority for exits".

But why not? It's easy to see how the Limit and Stop can get hit on the same bar on daily and higher (or even on 60/30 minute) scales on volatile days. A time based priority for exits makes total sense especially as you go higher in scale. In fact, backtesting without this on Limit/Stop exits can be totally misleading.

QUOTE:
Further reference: QuickRef tool > Position object > Priority.

Just because something doesn't exist, doesn't mean it shouldn't or couldn't, right? I know we are all collaborating here to make this tool the best it can be! Time based exits on a chosen intraday level for higher scales is a very limited feature... ideally, all indicators should have this available (and especially in streaming mode for "real life" trading, not just backtesting), given the current architectural limitations. But that's a request that's pretty sure to be DOA, so I won't even go there.

Position.Priority does not apply to exits. Let's not turn this topic into a feature request for WL. As you know, this topic is dedicated to the specific Priority enhancement methods from C.Components - exclusively. You might want to start a new thread for your questions. Thanks.

Apologies for my gaffe in post #29, now corrected!

QUOTE:
A time based priority for exits makes total sense especially as you go higher in scale.

How so? There's never a problem liquidating (exiting) a position at a brokerage and certainly not for testing either. No priority required!

But since you made me think harder about it, I can acknowledge that intraday equity and buying power could be affected by the orders of exits too. I honestly doubt this is much of an issue for 99% of the strategies out there, and besides, I don't think we're going to get there in Wealth-Lab.

QUOTE:
How so? There's never a problem liquidating (exiting) a position at a brokerage and certainly not for testing either. No priority required!

It's not about liquidity. On a highly volatile day a single bar could span both the Limit and Stop prices. Without a time based priority, the software could take an exit that was actually later in the day and wouldn't get taken IRL trading.
Issue is amplified on higher time scales - a weekly bar could easily be 10% up or down, so could a day although perhaps not as often, and so on. Although, it could really happen on any scale depending on how tight the limit/stops are. It's just easier to envision using higher scales.

If you're concerned about this in a Weekly or Monthly scale, it's easy to adapt any higher-scale system to Daily bars. That should essentially take care of it. I don't know what "IRL trading" is (I looked and google pointed me to Minecraft or something like it) but it's difficult for me to believe that one would have to be concerned with the intraday order of trades when simulating on Weekly or higher scales. After all, if you're exiting, you're only adding buying power for new signals at the end of week.

Sure, you could have some GTC limit/stop entries running too, but give me a concrete example where you've run into trouble. We're pretty good at coming up with solutions ;) Please start a new discussion dedicated to that.

QUOTE:
I don't know what "IRL trading"

"In Real Life"...

QUOTE:
it's difficult for me to believe that one would have to be concerned with the intraday order of trades when simulating on Weekly or higher scales. After all, if you're exiting, you're only adding buying power for new signals at the end of week.

A winning position could turn into a losing position if the Stop is taken by the software even if it occurred later in the day. And vice versa. This affects not only Buying Power for the following period (subtracted or added to erroneously) but all overall backtesting stats. I don't know how else to explain this. This might be one reason why many people question if backtesting results can match actual trading (slippage etc. notwithstanding) when they start to see differences.

QUOTE:
We're pretty good at coming up with solutions ;)

Agreed!
I think it's clear where you guys stand on this though, so new thread not necessary. Given the current architecural limitations, this would be a new feature (as Eugene pointed out)... and we all know where that bucket ends up ;)

QUOTE:
A winning position could turn into a losing position if the Stop is taken by the software even if it occurred later in the day.

Sure, but I'm still having a hard time seeing why this is a problem - except possibly for other "working" orders; but even in that case the effect on intraday buying power is minimal unless we're talking about an oversized position (say more than 20% of account equity) that drops 30% in one day. Even in the case, account equity drops only 6%, but if you liquidated the position (stopped out), the cash is immediately available to enter new positions for margin accounts. And remember, this cash was not available yesterday for other EOD orders.

At least with this example, I just convinced myself that exiting positions does not negatively affect intraday buying power for EOD orders. In the case of cash (IRA) accounts, exits can't influence other working orders at all because: 1) the cash in an exited position was not available when orders were entered anyway, and, 2) cash accounts usually* have to deal with the T+2 rule.

* This becomes more complicated when you consider "Portfolio Margin" (which in practice gives you more than 5:1 margin) or even "Limited Margin" option for qualifying cash accounts. (Video here).

Will a simulation be perfect? No. That's not possible. But in my IRL experience of actually trading mechanical EOD systems - using MOO and Limit orders, I can offer that order fills almost always precisely match my simulations using Wealth-Data. The only issue that I've had to deal with a handful of times are limit orders not being filled at the precise low of the day - and this is expected.

- I got off the "priority" discussion, and maybe it's because I haven't run into the use case, but I can't say that I've observed the problems with exits influencing entry priority, or vice-versa. Again, if you have a specific example (with numbers), I'd be glad to consider it.