Welcome to NexusFi: the best trading community on the planet, with over 150,000 members Sign Up Now for Free
Genuine reviews from real traders, not fake reviews from stealth vendors
Quality education from leading professional traders
We are a friendly, helpful, and positive community
We do not tolerate rude behavior, trolling, or vendors advertising in posts
We are here to help, just let us know what you need
You'll need to register in order to view the content of the threads and start contributing to our community. It's free for basic access, or support us by becoming an Elite Member -- see if you qualify for a discount below.
-- Big Mike, Site Administrator
(If you already have an account, login at the top of the page)
My strategy has been slowly evolving, and now I have about 7000 lines of code running in Ninja. (Actual trading logic is probably only 1000-2000 lines... a lot of other performance tracking, logging stuff in the background.)
I like Ninja's data handling, and I like using Ninja for backtesting.
The one thing I really don't like, is being "stuck" to Ninja's order handling. It means I'm stuck to Ninja's small set of broker adapters. I'm also looking to implement options trading, which isn't supported within Ninja.
So, I've been looking into converting over into QuickFIX. The obvious solution would be to build a class which basically implements all of Ninja's order functions (EnterLong(), ExitLong()), and order events (OnOrderUpdate(), OnExecution())... using QuickFIX.
I just didn't want to duplicate anyone else's work, if it's already been done. Any previous experience out there?
Stay tuned! I've had ups and downs, but am slowly making fundamental improvements (like selecting better instruments to focus on). Since June, I've had 4 consecutive up months (but did have some intra-month drawdown)... talk to me in 20 years, and I'll let you know how I did.
As far as autotrading, it's usually working very well. But to make this work I'm tracking all of my positions independent of Ninja... I have my own Order objects, track my own fills, etc, etc. Now, I basically leave Ninja with my strategy running 6 days a week, 24 hours a day. I shut it all down Friday night, reboot my machine, and then relaunch Sunday afternoon.
That said, there's at least one latent bug that I haven't been able to resolve... when I have two different strategies placing orders on the same instrument at almost exactly the same time (same bar), I believe there's a race condition in Ninja 6.5. The *quantity* of the orders may become wrong... I believe the quantity requested by the second order call some how overrides the quantity requested by my code in the first call. It's pretty hard to replicate, but I've seen the bug 3 times in the last month, so I'm pretty sure it's real. I'm just hoping Ninja 7 gets rid of it.
Only because I potentially have long and short positions of the same instrument... and EnterLong() and EnterShort() can't co-exist in the same strategy at the same time. Learned that the hard way.
So I have one strategy that only goes short, and another that goes long.
On NT7, this all gets easier when I don't use Ninja's order handling rules.
The "why" should be pretty obvious. I mean, it's strategy specific, so I won't get into it in too much detail... but I'll just say, it's profitable to have both.
The alternative way of implementing this (and it would save commissions) is putting another layer on top of the Ninja order code, and some how "sum up" the short/long orders to come up with some kind of a net position... and then place orders accordingly. That might work, but it really complicates the logic for what I'm doing in terms of tracking individual positions/fills. I prefer to think of these as independent positions, even though they're on top of the same instrument.
I suppose you could have two instances of NT running on different computers each with a different strategy... you might have to pay for two licenses, but that's a nit if you've got a good strategy.
NT 7 will allow to have both positions.
Holding long and short positions at the same time is possible using SubmitOrder, ChangeOrder and CancelOrder methods.
I don't know how "buggy" it is at the moment, but I like the ability. "Internal order handling rules" were big pain in the neck and somewhere else.
With a simple strategy (i.e. sell if some oscillator > 80, buy if < 20) there can be no disagreement between the long & short sides so you can easily put both in one strategy.
If things are more complex, and it's possible for both the long and short sides to want to be in a position at the same time, it can make more sense to separate the strategies for a couple of reasons.
1) It's simpler to code and test the long and short strategies separately. If both strategies want to have positions, logically it makes sense to be flat, and wait until only one strategy holds a position. This is exactly what you get if your platform allows you to be long and short at the same time, and it doesn't cost extra in commissions unless both strategies fire at the same time (i.e. closing positions at the end of the day). Total system performance is simply the sum of the long & short system performances.
2) The resulting system can be much more stable. If you put both long & short sides in a single strategy and let one "win" (i.e. whichever triggers first will block the other), then small variations in inputs can cause large variations in performance. In that case, total system performance is unpredictable and is certainly NOT the sum of the long & short system performances.
