Our mission is not to provide you with strategies, but to provide you with the fastest platform your hardware can yield.
The point here is that if the design of the platform is conceptually flawed, there is no way to make money with it. This is the core of the problem. First of all, you really need to show that it at least allows to make money. You need to show the design itself <b>allows profitability</b>. Most designs just don't. This is not a trivial task. This is actually the essence of the problem. And if even yourself, the creator, are not able to make money with it. Nobody will. Tom
Hi Under what kind of licence are you going to provide it? Will there be space to develop some extra codes myself? How to you weight the indicators (equally)? My questions seem probably newb. I would like to have an auto trader who trades auto with my risk aversion. Looking forward to give it a try!
absolutely agree. The OP misses the needs of his target audience completely. I am out of here because each and every time he engages others in language specifics rather than focusing on the ease and speed to test ideas and bring them to market. OP, I pointed out in an earlier post in verbose ways what I as strategist and trader look for. None of my points have you addressed. How come? I am out of here I was hoping to engage in an intelligent discussion of how development platforms help traders and strategists but ended up in a coding monkey corner. Have fun to those who enjoy spending their time on language specifics.
could not help it to post this last comment: Buddy, coming up with a platform that uses a symbolic language such as EL is a total one-way street and wont attract any serious attention in your endeavor. Good luck re-inventing wheels that were created decades ago. By the way, I chatted with the Deltix guys and their platform looks extremely interesting and up to the task, though when I heard about pricing I was almost falling out of the window, north of 120k USD. You mentioned that platform and judged it as being useless in one single sentence. Not sure where you take such authority from, I doubt you ever tested the platform.
We haven't decided price structure or any monetization mechanism. It comes with its own language compiled 64bits native with THE SAME optimizations found in a C++ Optimized Compiler. What this means is this: the fastest you can get. One interesting aspect that can be different and I haven't seen in other platforms is that everything is data oriented. You don't start with a chart or a symbol list created by a user clicking on a menu... Creating a chart from the Menu will really execute a small program like this: (the real code is almost exactly like that) PHP: main() { DataSeries msftDataSeries = DataManager.request( "SELECT open, low, high, close, MovingAvg(close, 20) FROM MSFT WHERE interval='D' AND fromDate > '2005-01-01' AND ticks=true"); UIWindow myChart = UI.createInstance("Chart"/*name of UI module*/, "MyChartID"/*window ID*/); myChart.addDataSeries( msftDataSeries ); myChart.run(); } -UI is a singleton that lets you create and interact with UI modules. UI Modules can be developed by anyone. By default we are going to have these UIs: a chart, a symbol list, a console window, a level II, time and sales, 2 more windows with a proprietary graphic displaying (his is going to be very good), news window, order entry bar, accounts and report. -the DataManager is a singleton (not really a singleton, but one [or more] per core, it looks like a singleton from the outside) that has several request methods including the one on top with our own SQL dialect MHDQL. -MovingAvg is a user written âprogramâ that runs in the server. It is very possible that by the time you make that request nothing gets executed on the server or not even in your PC. Only the ticks will make this function to execute on your local PC (here you see the duality of client/server execution of user programs). You can expand the platform in any direction: Your own UI, your own strategies/indicators, your own data provider.
As a general premise, I have some general personal reservations for designs where one expects people just plug in strategies into his program to be executed. What would be the benefit ? If they can code at that level, they would just directly route to the broker or the exchange, with much greater flexibility. But i might be wrong on this (personal opinion) and I like to hear different views. In any case, if one has to code, he would like to (to be able to) use VB.net and C#, for sure (i.e., the modern "non-masochistic" languages). Therefore the host application must be able to perform on the fly .net compilation of user's programs. As to design compatible with profitability, there are naturally many ways to create "systematic unprofitability" by design (it's clearly easier to create unprofitable frameworks). An example could be a trading engine which restricts the user to "strategies" having the following "structure": Compute realtime one or more user (statistically predictive) "indicators", say V1, ..., VK Make an Entry when a given condition, function of the indicator occurs. Make an Exit (possibly with a trailing stop) after a target profit is reached, or when a given loss threshold is reached. This would typically generate beautiful results and equity curves in backtesting ("curve fitting"), but substantial losses in live trading in the long term. Tom
If a user can code the whole "platform", it doesn't necessarily mean that this us where the "payout" is the highest. Like you point in your earlier post, a user could start with coding a text editor... but this isn't where added value is. The reasons to use an existing platform are to take advantage of (in no particular order): 1) Support for market interface. A few brokers change their API often. Here the makler of the "platform" will take care of any changes and the user will have to apply a patch at some point. Saves some time that can go towards making a profitable strategy. 2) Collecting and saving market data. Hopefully, the "plaform" creators gave it some thought so that this part doens't lag horribly when market activity increases. Can be done but this where sloppy code can really backfire. Happened on earlier version of NinjaTrader. 3) Doing "housekeeping" with orders. Maintaining list of open orders, cancelling them in some systematic way when needed, calculating position, making sure any order placed wouldn't increase position beyoned the desired maximum size. The next level of "housekeeping" may include making sure that ordrs marked as "exit position" are never placed unless the system has a position to close; or not placing a stop order in the market price is sufficiently close to stop price (may dramatically reduce order modifications with the broker). This second level of "housekeeping" lets the actual trading strategy contain less code that is not relevant to the logic of the strategy.4) Backtesting. Yes, writing a simple backtester is not a huge task. Moreover, a purpoise-built backtester will probably be massively faster than most out-of-the-shelf backtesters due to not having all the unnecessary "fat" like creating order objects. However, adding bells and whistles to it is not a small task. Using out-of-the-shelf one frees more time to work on the logic of the trading strategy. 5) A good backtester-simulator helps test order-handling logic. Are partial fills and rejected order handled appropriately? Are delays in order placement taken into account? etc All of the above are doabe for someone with decent programming experience and understanding of pitfalls in market dat acollection and backtesting. The question is whether a person wants to create all of the above (spending perhaps a few years as a lone developer) or whether he/she wants to concentrate on finding and improving profitable trading ideas. Another aspect is testing. The features are likely to contain a few bugs. A platform used by a few thousand users rather than one user will hopefully have most serious bugs fixed fast as people may give heavy use to different parts of the platform and report problems. On the other hand, when a problem is found the only thing a user can do is to pleed with the developers to fix it, However serious the problem is or however trivila the required fix is it will be up to the developers when to fix it and whether to fix it at all. A "home-made" platfrom can be fixed by the user himself at the earliest convenience. Haha! I like how you call C++ "masochistic". Just last night I spent over an hour finding out that a reference to an object was becoming invalid due to the object being moved to a new location (by copying). This is something that would never happen in C# or Java. When you mentioned platforms incompatible with profitability I thought you were talking of fatal flaws in order handling or forward looking bias in backtesting. For example of forward-looking, a few people assume that they can use the closing price in generating a signal and execute on the same closing price. That's a very strong assumption for a backetst. A more reasonable one would be executing on the next open price. Tom, in your post you basically say: A trading strategy has an entry signal and an exit signal. How can a strategy work in a different way?
If we are talking that everything developed for the platform has to be in a symbolic language, I can't agree with you more. Not only a few people have as strong views on what language is "the best" as Mhtrader but also new platform users are likely to come with masses of legacy code thay may want to port in an easy. Further, it's a very difficult task in its own right to beat editors and debuggers that come with moder IDEs. Denying users the ability to use these can't be considered a useful "feature". On the other hand, having a built-in scripting language in addtion to the ability to use popular compiled languages can't be all bad. Using a 2-line script for colouring bars on a chart or some other visualisation can actually save a bit of time and effort here and there.