Quote from NetTecture:
You know, you are right, but "running behind into a runaway position" is a no no that you learn in every book 
I was shocked that they even say this is a great new feature.
Their alternative, though, is that the strategy will go in the next time it is flat. THAT makes a lot of sense. Wait until the strat and the account are in sync, and then reenter.
Right now their approach is known ignorant, which is why they change it - basically they just trade from the strategy, assuming the account is in the correct position. THis IS dangerous (and I would appreciare at least getting a dialog up when a started strat and the account are not in sync).
But seriously, just jumping in is not smart. Many reasons, one m
y be that the strategy even takes a HIGHER risk than normal, because - knowing that is has a hugh profit, it adds some of that to the trailing stop. THere you go - strategy started, you are long at the end of the move with a higher risk than ORIGINALLY allowed and planne for (for new positions)
I like the idea with array boundaries, but seriously - from my side as programmer - I am not sure the solution is good. Not in term of programming, but what the heck are you returning? 0? Oldest value? Any statistical analysis will be skewed. If you dynamically reload the proper data and return that - great. For any other soltuion I am not sure I want to get it - I personally would prefer to get exceptions. I have to add, though, that I am a die hard programmer
Well, it does throw an exception, of course. Allow a more clear explanation. The exception gets thrown with complete information. But the data engine also catches it itself so your code never sees or has to handle it. Then the engine simply takes note of your method along with the array and value that was out of bounds . Then it waits until there there ARE enough bars in that array and continues. This has been thoroughly tested and works perfectly. So it all works transparently as it does in EL.
NOTE: If you do happen to use some insanely high value and it can never resolve, the data engine realizes that at the end of the historical run and then gives you a full stack trace explaining the problem and which line you have the error.
In some very RARE situations you can get a cross dependency that it can't resolve and so it throws a stack trace to exactly explain the line numbers in your strategy so you can solve it.
The real difference in platforms is that this platform is one actually used and developed by a trader/programmer while building and testing strategies. When you as a programmer actually use the work on tweak and testing ideas repetitively, every little tool to speed up development makes a big difference.
Microsoft calls this "eating your own dog food." It means that the developers need to actually use the software themselves on a regular basis to really understand the user needs better than ever possible through "requirements gathering" exercises.
That's why I want you to work on the GUI rather than some other "hired gun".
Here's another one. In other platforms even with C#, it's useless in the debugger to look at the high, low, close, etc. It's because internally they use advanced type of arrays which aren't linear so you can't make any sense out of them. It makes debugging your strategies hard.
While internally, the same is true for TickZoom since it has some powerful optimizations, dynamic and circular arrays which are meaningless in a debugger....it automatically "figures out" that you're viewing it from the debugger and instantiates a completely user-friendly array view. So it makes debugging your indicators or strategies data values far easier.
Soon, tickzoom will go another step farther and implement full trace with Log4Net using contexts so you can filter and look at logs of only a specific symbols, on a certain bar of the chart, or follow a single tick through all of it's steps through the system, etc.
That logging is necessary because using the debugger is getting harder due to all the reentrant code from multi-symbols, time-frames, etc. Contextual trace filters will make debugging a breeze.
There's tons of little things like this that make a huge difference in productivity simply because the platform gets used by developers who constantly tweaks and improves the strategy development experience (just like you would on NT if you could). Not only myself but because it's open source so other users also add in tweaks and ideas and that's why it works so well.
I still don't wish to knock NinjaTrader. A lot of people love it for discretionary trading. The only frustration that you and I have is because we're programmers and know better ways to do things for automated trading we get turned off by any closed source system because he have the ability and are "caged off" from fixing the issues ourselves.
Quote from NetTecture:
Btw., I will always call dump things dump. Here is another one. That is current.
* There is a grid showing all running strategies. Running strategies are green.
* WHen an exception occurs in a strategy, it is not executed further.
* There is a log entry in the log section in yellow about that. It does not contain the strategy name.
* The strategy in the grid STAYS GREEN. THis is gross neglect. There is no alarm, no popup, no notification. The failing strategy just stops. Even positions are not closed, at least they were not when that happend to me.
This is totally upside down. I get sound notifications when the strategy puts in an order or I get a fill. Not saying I dont like any notification, but these may be minor events for me (Imagine skalping strategies, 4-5 on 6-8 instruments each - that is a LOT of trades going in and out).
But a strategy just killing itself is no sound alarm, no popup. The strategy does not even turn away from being green (indicating it is still running). All is a single YELLOW line in the logs.
THIS IS DUMP. Sorry. No political correctness will help here. A lot of stuff can be argued about, seen as bad implementation, not important etc. For me, a failing strategy is a LOT more important than the fact that the strategy just entered some orders into the market. Even worse - if I watch the strategy grid, I see them entering and going out of the market. I Just dont see it crashed. Ups
But allowing a strategy to keep positions in the market potentially unprotected (because the stop loss entry may have blown, actually) can result in serious losses, and by DESIGN the application sees that as less important to notify the user than the entry of a new order.
Sorry. Neglect like that makes me upset. Sorry, in my projects that gets fixed in an emergency fix. Not argued with.
Well, I see your point. My impression is that very few people actually try to use the total automation in NinjaTrader for all these reasons and others reasons besides.
When I say people love Ninja and I like it also, it has to do with discretionary trading and the ATS where you can setup automated rules after you enter a strategy (discretionary) on how to close it out, etc.
Plus the SuperDOM and other things for discretionary is rather cool.
But I certainly don't recommend it for hands free automated trading--certainly not prior to NT7. Maybe NT7 is better. Although some do use it for automation because they couldn't find any better options. So they have to write or build a lot of work arounds to try to make it reconnect or restart properly when there's an outage, and so forth.
NT is good software, it's just targeted to discretionary traders.
To be really for automation, it needs a separate server to run automation without a GUI rather than requiring such tight integration with a GUI.
I think others also complain because on restarts it handles back fills poorly.
Perhaps the NT7 solves some of these.
tickzoom solves all these issues because it only supports automated trading and historical testing.
Wayne
