Taking Partial Profits

[molecool]

Let's say I have a strategy that goes long 100,000 units on the EUR/USD as such:

entryOrder = EnterLong(1, 100000, LONG_POSITION);

As it runs the strategy is supposed to take 25% partial profits when it reaches the 1R mark. Although I have coded pretty complex strategies which override onExecution and onOrderUpdate I have never taken partial profits. Do I simply exit with a partial amount?

exitOrder = ExitLong(1, 25000, "Exit Long Position", LONG_POSITION);

Is that it? Will I still be long 75,000 units after that? I am just wondering if that is all there is to it.

Also, I will have to update the quantity in my stop as well, right? So do i overwrite the the stopOrder.quantity manually or is there a special call to make?

Any input would be appreciated.

[koganam]

Let's say I have a strategy that goes long 100,000 units on the EUR/USD as such:

entryOrder = EnterLong(1, 100000, LONG_POSITION);

As it runs the strategy is supposed to take 25% partial profits when it reaches the 1R mark. Although I have coded pretty complex strategies which override onExecution and onOrderUpdate I have never taken partial profits. Do I simply exit with a partial amount?

exitOrder = ExitLong(1, 25000, "Exit Long Position", LONG_POSITION);

Is that it? Will I still be long 75,000 units after that? I am just wondering if that is all there is to it.

That is intuitively what we would expect, and indeed is what is described in the NT Help. However, it appears that there is something not quite so kosher about the reality of it. Being the anal-retentive person that I am, as is my wont, I would suggest that you read this entire thread, so that you get the full picture.

ref: http://www.ninjatrader.com/support/f...858#post323858

The long and short of it, is that you may be better breaking up your entry into multiple entries as a scale-in, scale out method.

Also, I will have to update the quantity in my stop as well, right? So do i overwrite the the stopOrder.quantity manually or is there a special call to make?

Any input would be appreciated.

IOrders are read-only so you cannot quite do that. What you want to do is to reissue the IOrder (with the same name), using the amended quantity, which would replace the object, instead of modifying it. We both know, that is just an artifice to get around the read-only nature of the object.

[molecool]

IOrders are read-only so you cannot quite do that. What you want to do is to reissue the IOrder (with the same name), using the amended quantity, which would replace the object, instead of modifying it. We both know, that is just an artifice to get around the read-only nature of the object.

Thanks mate - how would I 'reissue' the order? Never done that either... sounds scary ;-)

[molecool]

That is intuitively what we would expect, and indeed is what is described in the NT Help. However, it appears that there is something not quite so kosher about the reality of it. Being the anal-retentive person that I am, as is my wont, I would suggest that you read this entire thread, so that you get the full picture.

ref: http://www.ninjatrader.com/support/f...858#post323858

Given the complexity of my strategy I do not think splitting up orders is going to be an option. The only way I would be able to accommodate the required functionality would be to do it as initially proposed. In a nutshell - what is the biggest problem you have encountered using the 'simple' approach?

[koganam]

Given the complexity of my strategy I do not think splitting up orders is going to be an option. The only way I would be able to accommodate the required functionality would be to do it as initially proposed. In a nutshell - what is the biggest problem you have encountered using the 'simple' approach?

As the thread that I pointed you to shows, it simply does not work right if you are using managed orders.

[koganam]

Thanks mate - how would I 'reissue' the order? Never done that either... sounds scary ;-)

If you want to change a Stop Loss, whether quantity or price, just issue the exact same IOrder with an amended whatever you want to amend: price, quantity ... Just the same as if you were using IOrders to manually trail a stop. It is just that in this case you are probably going to change the quantity rather than the price.

However, as the thread I pointed you to documents, this does not work properly, and is an acknowledged bug that, apparently, will not be fixed in NT7.

[NinjaTrader_PatrickH]

Hello molecool,

Thank you for your post.

As koganam points out this is a noted bug that will be resolved in NinjaTrader 8. However, this is only in relation to ExitLong() and ExitShort() which are market orders ExitLongLimit()/ExitShortLimit() and ExitLongStop()/ExitShortStop() will work.

[koganam]

Hello molecool,

Thank you for your post.

As koganam points out this is a noted bug that will be resolved in NinjaTrader 8. However, this is only in relation to ExitLong() and ExitShort() which are market orders ExitLongLimit()/ExitShortLimit() and ExitLongStop()/ExitShortStop() will work.

Not quite Patrick. At least not according to the Product Manager, who wrote this:

koganam,

Hopefully this will clear the air a bit. Both your and Serac's examples are scenarios of using ExitLong() market orders to try and scale out. Using market orders to scale out works in backtest, but NOT in real-time.

So to summarize this all up it is like this currently.
- ExitLong() scale out in backtest <-- works
- ExitLong() scale out in real-time <-- bugged
- ExitLongLimit/Stop() scale out in backtest or real-time with same fromSignalName <-- not designed to work in this manner
- ExitLongLimit/Stop() scale out in backtest or real-time with unique fromSignalName per scale out "leg" (a.k.a. you scaled in) <-- works
- unmanaged approach's SubmitOrder() scale out in backtest or real-time <-- works regardless of signal names

here: http://www.ninjatrader.com/support/f...77&postcount=6

[molecool]

If you want to change a Stop Loss, whether quantity or price, just issue the exact same IOrder with an amended whatever you want to amend: price, quantity ... Just the same as if you were using IOrders to manually trail a stop. It is just that in this case you are probably going to change the quantity rather than the price.

However, as the thread I pointed you to documents, this does not work properly, and is an acknowledged bug that, apparently, will not be fixed in NT7.

NT support maintains that this is only broken in the market order calls. The limit order calls via unique identifiers are supposedly unaffected. Are you saying that is untrue? I really would like to get some clarification on this before I spent several days coding for nothing. Thanks!

[koganam]

NT support maintains that this is only broken in the market order calls. The limit order calls via unique identifiers are supposedly unaffected. Are you saying that is untrue? I really would like to get some clarification on this before I spent several days coding for nothing. Thanks!

molecool, when I deal with a company, I usually look at the hierarchy, in which usually the "Product Manager" would be a bit higher than "Customer Support". That is why I suggested you read the entire thread.

In any case, this is what the "Product Manager" wrote. What is to be believed is a matter of preference.

ref: http://www.ninjatrader.com/support/f...63&postcount=1

[molecool]

molecool, when I deal with a company, I usually look at the hierarchy, in which usually the "Product Manager" would be a bit higher than "Customer Support". That is why I suggested you read the entire thread.

In any case, this is what the "Product Manager" wrote. What is to be believed is a matter of preference.

ref: http://www.ninjatrader.com/support/f...63&postcount=1

I used to work as a SWE back in the days and although I'm sure there are exceptions PMs used to be the least technical people in the various projects I participated in. Be this as it may - this is serious enough that it should be very precisely documented. Otherwise it would be a major FAIL on NT's part and seriously question their use as a semi-pro trading platform. I very much hope that someone can shed some light on this as I do not enjoy wasting time on inherently buggy code.

Now that said and not trying to be overly negative - I understand that bugs happen and (although I'm very surprised there wouldn't be an NT7 maintenance update to address this problem) a clear answer on what works and what not would be appreciated.

[koganam]

I used to work as a SWE back in the days and although I'm sure there are exceptions PMs used to be the least technical people in the various projects I participated in. Be this as it may - this is serious enough that it should be very precisely documented. Otherwise it would be a major FAIL on NT's part and seriously question their use as a semi-pro trading platform. I very much hope that someone can shed some light on this as I do not enjoy wasting time on inherently buggy code.

Now that said and not trying to be overly negative - I understand that bugs happen and (although I'm very surprised there wouldn't be an NT7 maintenance update to address this problem) a clear answer on what works and what not would be appreciated.

Having been a Product Engineer in a previous life, I understand your sentiments about technical ability of Program/Product Managers. Generally, I have found Product Managers to be pretty technically astute: and this is a Product Manager, not a Program Manager. Moreover, this is more in the realm of Product Specification and Bug Tracking. Those are prime functions that Product Managers usually track rather more meticulously than Technical Support would, or sometimes even can.

Moreover, if you read the thread, you will notice that Ray, the CEO, who for certain can write code, whether he still does so currently or not, also weighed in on the thread. I am reasonably sure that with his imprint, and my subsequent direct challenge to his response, we have the correct documentation of the situation. It is a bug that I hate, but at least, they have acknowledged it.

Ultimately, because of it, I had to fall back on an unmanaged approach, to handle this particular kind of instance, rather than my preferred managed orders approach.

[NinjaTrader_JoshP]

Hi koganam and molecool,

I understand there is some confusion around what the bug is here and unfortunately it seems to have caused a bit of hair pulling. This bug was personally tested and confirmed by myself several months back in the original thread koganam and Serac had discussions in.

Koganam's grasp of the issue is pretty spot on. Unfortunately the bug in NT7 revolves around trying to scale-out without scaling in first. What my colleague wrote earlier was not entirely clear as to the circumstances in which an ExitLongLimit/Stop would/would not work. Hopefully I can try and clear this up.

Here are the scenarios available:

Scenario 1
- Single entry order for multiple contracts (Doesn't matter if it was an EnterLong or EnterLongLimit/etc.)
- Multiple ExitLong orders of smaller quantities to scale out of that position generated from a single entry order
- Backtesting <-- works
- Real-time <-- does NOT work. Bugged. Will NOT continue to scale out of the position. Has been tagged for resolution in NT8

Scenario 2
- Single entry order for multiple contracts (Doesn't matter if it was an EnterLong/etc.)
- Multiple ExitLongLimit/Stop orders of smaller quantities to scale out of that position generated from a single entry order (a.k.a. exiting the same fromEntrySignal name)
- Backtesting <-- expected to NOT work
- Real-time <-- expected to NOT work
- NT's managed approach was not designed to allow for closing the same fromEntrySignal twice in this manner. You will get a message like this: "There is already a matching filled order in place". This was not meant to work this way and won't work this way.

Scenario 3
- Multiple entry orders to acquire multiple contracts
- Multiple ExitLongLimit/Stop orders of quantities matching the entry order quantities
- Backtesting <-- works
- Real-time <-- works
- When using entry orders A, B, C and corresponding ExitLongLimit/Stops with matching quantities of A, B, C, you will be able to scale-out properly. Note that each exit order is associated to its own entry order.

Scenario 4
- Unmanaged approach
- Scale in/out works regardless of what you are doing

molecool, from my understanding of what you are trying to achieve, unfortunately the current options available are either scenario 3 or 4.

[molecool]

Hi koganam and molecool,

molecool, from my understanding of what you are trying to achieve, unfortunately the current options available are either scenario 3 or 4.

Thanks to you and koganam for clearing this up. But per your last statement - damn, this really sucks. I don't think this is possible for me. My strategy is extremely complicated with a lot of messaging, rules, money management, position size calculations, currency calculations, etc. - the works. Splitting up orders would make my life very very difficult.

FWIW - and I'm not trying to be negative here: WHY in the world was this not tagged to be fixed in NT7? I mean, it's something extremely crucial for a professional platform. And I have not even heard about a release date for NT8. Plus once released NT8 would not be stable enough for at least another year to be considered for a production environment. You guys are professional SW devs - this is certainly not your first dev project. Knowing that - what led to this decision? Is there any way you would reconsider adding this fix into NT7? Pretty please?

[NinjaTrader_JoshP]

Hi molecool,

I understand it is a major inconvenience in complicated strategy code. I wish I could fix it in NT7 too. For this particular bug I drove many discussions with our development team investigating different approaches to try and get this done, but unfortunately the nature of this bug is all the way down to the core handling of the managed approach. It would require a bit of nasty overhauling in this extremely sensitive area of NT code. The risk of things breaking is extremely significant since there are so many intertwined components here that unfortunately we will not be able to address it in NT7. I wish I could give you a different story here, but can only thank you for your understanding and patience on this matter.