I'm a relatively new trader. I have a background in software engineering. I recently have been looking into scanner software. (Metastock, Tradestation 2000, Ensign, Wealthlab, AmiBroker and others.) It seems as though every software package is lacking in some respect. Reference this thread by xicaju. http://www.elitetrader.com/vb/showthread.php?s=&threadid=3286&perpage=6&pagenumber=1 I'm going to try to keep this post as simple as possible so that traders without a programming background will understand and hopefully contribute. I'm going to describe my idea of the "Holy Grail" trading software. I would very much like thought and feedback from others. If it is positive and there is enough interest, I might develop this software. The software will be comprised of several modules. The primary module will be the Scanner Engine. The Scanner Engine is a task that will continually run. It will have the ability to spawn child instances of itself. Each instance of the Scanner Engine will interpret and continually execute "Scan Scripts". The concept is to keep the syntax of the Scan Script language as simple as possible so that lay people can design their own scans. The Scan Designer module will be a GUI (Graphical User Interface) application that will generate Scan Scripts. Think of it like Visio. The user will drag icons that represent Scan building blocks onto a drawing area. Each building block will have one or more "Properties" or values that can be set. The blocks will be connected together with varying types of connectors. The Scan Engine will have an interface to the "Data Store". The Data Store will be a database of historical data that is stored on a relatively local or same machine as the Scan Engine. The Data Store will house and cache historical data. The data store will have a layered API interface with multiple data sources and will retrieve and cache real-time and historic data from the data sources as it is requested from the Scan Engine. The Data Store will be designed in such a way that there will be an installable driver for each data provider (TAL, Esignal, DTN, etc) Think of it as installing another printer under windows when you want to add or change data providers - you just install the driver. The Scan Engine will also have an API (Common interface) and installable drivers to output the scanners results. Several output type drivers could exist. Examples would be Minders and Watchlists in your favorite charting software, log files, printers, links to other programs like Excel, Quicken, etc. The Scan Engine would also have a trading API and drivers to direct access trading platforms. The idea is to be able to fully automate trading strategies if desired. Hedge and arbitrage setups are examples of some auto executable strategies that could be done. This software concept just came to me and is still very much in its infancy. Comments are welcome. Mike
Most of what you described, plus some things you haven't brought up are being done in private trading houses. All you need is about 20,000 man hours to implement it. If it is for yourself or a trading company with deep enough pockets and a couple of years you have the concept.
I am actually working on a scan type aei multi-factual scaning wizard linked directly up to an fop type split time dividing interface. What a clown!!
Metooxx Could you please elaborate on some of the things that I haven't brought up. In your opinion, is there a need for software like this? If it existed would you use it? Thanks, Mike
This is not a 20,000 man-hour project. It could be done by one person in under a week using the proper tools. I would write everything in Matlab, including the GUI. The quantitative code would be concise, elegant and fast. You can do a single line of Matlab code what would take tens of lines of C code. You also get built-in numerical routines, charting and array/matrix operations which dramatically reduce the need to use "for" loops and "if" statements. Debugging becomes ten times easier because Matlab is fully functional, semi interpreted, strongly typed, and uniformly double precision in its math operations. If you use mainly array operations, there is very little performance hit versus compiled C code. If you still need loops, you can always convert Matlab code to C and compile. Matlab is the most powerful language for data intensive math, when you consider the entire design-debug-test cycle. Yes, other languages may be faster. Do any of you use Matlab or numerically/data intensive quantitative analysis? -J
Bullfighter - It's not a new software concept. The issue is practicality and viability. A successful mechanical trading system isn't just about number crunching. If it was, jaypaul could do it in a week in Matlab and sell it for a million dollars...LOL And it's not necessarily about "scanning" unless maybe you're trying to implement some very fast arbitrage plays or maybe some very short timeframe momo type setups. The basic problem is in the problem statement itself. The problem isn't whether you can scan 5,000 stocks in realtime based on elaborate numerical crunching. The problem you really want to solve is how you will trade profitably. That's the ONLY problem to be solved. Rather than worrying about scanning a universe of stocks as you outlined (which would at best be extraordinarily time consuming to build - if you ever got it to work acceptably - or incrementally better than existing systems), you'd be better off focusing your efforts on the single problem - making money at trading. Develop a system that traded one or two specific instruments with high success (e.g., the S&P or NDX futures) - if you can do that, you're set - whether you jut traded it yourself or sold it. For what it's worth - if you're inclined to try to build a mechanical trading system, forget the grand holy grail and focus your energy on a system that will trade the e-minis profitably and reliably. That alone will be a difficult enough challenge for someone with limited trading experience (regardless of the software experience). Good luck.
Yes there is a need, however the groups that need it already have developed it for proprietary trading. We already use it. The development time to market and the costs in programming hours is so prohibitive that it could not be marketed for a price that the average trader would find appealing. The changes necessary to keep an edge take it out of the normal software development cycle of prototype, alpha, beta, and production. The problems are so specific that it takes a team of developers to keep up with a specific trading style. The prototype code is typically run in production, with bug fixes on the fly; something that a commercial release could never do.