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)
Looks like fun, keep us posted. If you are using external data, you might want to try the libSVM library as that is MUCH faster than the ACCORD version. ACCORD is nice because I can easily integrate it into NinjaTrader, but for research the libSVM could save you days in time. I had one run on ACCORD that took 36 hours and a similar test on libSVM took only 5 hours (not identical).
Also, for sequencing, I have always thought HMM might work better. I haven't any experience with that library yet, but should be good for developing the probability of something based upon the last sequence of something.
Roger HMM for sequences--will likely have another look, for now via Accord.Net. I reviewed the topic briefly some time ago for the reason you suggest but took another path at the time. Happily I'm not a poet (i.e., Robert Frost) so have no problem retracing my steps to go down the Road Not Taken
Regarding the length of time Accord.Net SVM engine takes to process a training suite, not sure what the issue is but coding efficiency aside notice the learning part of the code at least appears to be single threaded. Not having studied the source I don't know if it lends itself to multithreading or some other form of distributed processing (e.g., CUDA), but it may be you and [MENTION=1]Big Mike[/MENTION] have given it some thought.
Edited to add: Visual Studio just advised one of the reference DLLs in the Accord.Net HMM sample app (might have been Controls) requires a .Net version > 3.5 as specified in the project properties. If so this might have implications for NT, which may still depend on 3.5.
Edited to add: Using the Accord.Net framework from the CodeProject site the namespace MarkovSequenceClassifier referred to in the sample HMM app, which probably ought to be in reference Accord.Statistics.Models.Markov, is not (or is no longer) present in the DLL (or apparently in the entire Framework either). Not sure what to make of that at the moment.
In other news it occurs to me another reason HMM might be appropriate is its ability to handle sequences of different lengths during classification, something one has to deal with if using Zig Zag to generate sequences.
Should add a note on machine learning feature filters for future reference, to wit that while Zig Zag provides a decent filter for sequence generation, use of a cycle oscillator (e.g. stochastics, MACD in a pinch) is another approach that exploits the fact an oscillator may be better tuned to a given trading strategy and time frame, assuming one uses an oscillator at all.
In other words, the stock Zig Zag logic will give us swings based on a fixed % price change or point spread, whereas an oscillator may give us swings more consistent with the swing a strategy will tolerate. The fact that Zig Zag determines pivots in hindsight, long after the moment has passed, is not an issue any more than the fact cycle oscillators are lagging indicators since we're analyzing a chart to extract features, not trading. [In fact when trading I pay attention only to oscillator divergences, which divergence I (and many others) consider leading indicators, for setups and to slope of the higher time frame momentum oscillator for entry].
The 3 charts (1800-, 600- and 200-tick EUR.JPY) in the figure below illustrates the difference. In the figure the blue box in each chart contains what these days I would consider one long trade since it spans the period in which both Stochastics %D was above 50 and MACD above zero on the 1800 tick chart (left hand side of the figure).
In each chart the Zig Zag indicator with a 0.1 point minimum swing is applied to close price (shown in cyan). A modified Zig Zag indicator, also set to 0.1 minimum swing but which picks the high of the bar for swing highs and the low of the bar for swing lows is shown in yellow.
Considerable difference can be seen between the behaviour of both Zig Zag indicators and the behaviour of the oscillators in the bottom panels of each chart (MACD(5,20,30) and Stochastics(3,5,2) during the "trade". In the case of stochastics this difference is due in large part to the fact there is in general no reliable correlation between size of price movement and size of e.g. %D movement, yet IMO stochastics gives a better idea of what traders are up to at any moment than eyeballing price pivots alone in hindsight.
The point is choice of filter method & parameters greatly influences the nature of the feature vectors extracted.
Having said that the following issue arises. If one is going to consider extracting feature vectors using a (dynamic) oscillator swing filter instead of a (kinematic) Zig Zag filter why not consider filtering by the entire trading methodology? I don't mean to imply trying to filter based on setups predicted by the trading methodology, which (the equivalent of a bot) would be very hard if not impossible to implement, but rather why not extract feature sets filtered by actual trading outcomes somewhat the same as Monte Carlo analyses are applied? In other words, why not capture features or sequences that led to each trade as the input data set, using the outcome as the classification? This approach essentially uses the state of our trading brain at that moment as the filter, presumably comprising everything we know about our trading method albeit distracted as it might be by emotion and fatigue--far more than we could easily code. This way we are working toward encapsulating our trading method in a bot and perhaps even improving it, as opposed to writing a bot that especially in the case of Hidden Markov Models applies criteria we know not what.
Given that geeks like me (like one of a million monkeys coding) will some day accidentally extract the complete works of Shakespeare as a feature set little doubt this approach has been taken by others and if so at this point I'm curious what conclusions were drawn.
Making this post as a penance. These days I may make a half dozen relatively boring trades a day, pack it in around noon local time and get on with my life. Over time it's easy to slip into a rut and lose focus--kind of like dozing off at the wheel when driving and when it happens we have to take it seriously. In this case it was not so bad, worst moment down only $100 or so, but a mistake is a mistake and any mistake can end up costing real money if not nipped in the bud.
Moreover this error is in a category I thought I mastered a long time ago but apparently not--entering trades impetuously, without thinking them through.
Finally, while there was a time I would congratulate myself at having managed to turn a bad entry around I've learned since then that the market sometimes overlooks mistakes and even rewards bad behaviour occasionally, and when it does we should be very afraid; it's one way the market sets us up to clean us out.
Sequence of events
Last trade of the day around 11:00 EST, trading since London open and tired but happy after a profitable session, turns out not so much happy as over-confident & feeling greedy.
The following sequence of images tries to capture the right hand side of the charts I trade from as I entered the last trade of the day (short 1 contract USD.JPY), the point I realized the mistake I'd made and how the market let me weasel my way out of it.
What I saw: On the 200- and 600-tick charts price in free fall above an abyss devoid of visible support. What I should have seen: The bear climax bar forming on the 1800-tick chart. The more rapid price movement the greater the vacuum, both bulls and bears standing aside, waiting until it's run its course before going long and closing shorts, respectively.
What I did (next 2 images): Sell at the lowest possible price, on impulse. What I should have done: Whether I noticed the bear climax bar on the 1800-tick chart or not I should have remembered:
1. there is never an abyss. Just because support is not marked by a line on the chart does not mean it isn't there, like the magic number 50 that I sold into .
2. one never trades a breakout/spike/gap or any rapidly moving price action without have anticipated it previous to the movement and planned for it and for its reverse.
3. when one hasn't anticipated a movement one waits to see how it plays out. In this case probably 90% of the time one can assume a retracement is imminent, at which point all will be revealed.
4. worst case waiting means a missed opportunity, which is a far better outcome than foolishly taking the trade and risking the worst case outcome of being in the market on the wrong end of a trade--losing a ton of money.
What happened next Price action plays out, indicators catch up, divergences scream reversal. Fight or flight kicks in and the mind finally focuses: bail with a relatively small loss now or double up at high probability resistance and risk a full boat loss later.
What I did: Fight--double up at R1. While I put the short order in place ahead of time I was prepared to yank it. It was now a calculated risk Price action and indicators suggested estimated to be 50/50 so I went with the Hail Mary.
What a full blown reversal looks like Exited with a small profit when price rebounded off R1. As a newbie when price gave me a chance to bail I'd assume instead I'd been right after all--being right was important back then--and I would have stayed in the trade to see how much money I could make. Now I get out the instant the getting is good.
For anyone anticipating the release of code promised in an earlier post or more thoughts on machine learning, it's in process. Code is ready but still collecting my thoughts. The main issue may be whether to wait to publish final analysis of Accord.Net behaviour (and plans for mods to the Accord .Net library), first impressions of the libSVM library and plans for more classification experiments. Hidden Markov Models are on a back burner.
The slow turn around is influenced by the main stumbling block, which remains my obsession with coding my discretionary short time frame method, which has proven itself and ought to be coded. I've done more experimental coding but so far the essence--the brain computer connection--continues to elude me.
Funny how bleeding edge stuff that is not profitable but is easy to talk about comes naturally, but old school stuff--what puts turkey on the table--is so hard. I speculate the bleeding edge stuff is just stats revisited--a new, cool look and feel, just like new, cool computer languages merely wrap the same old machine code in Gen X/Y/Z think.
In my experience, and despite my best efforts, so far computers can't think.
When I was younger someone proclaimed the Interwebz ushered in the foundation of (the equivalent of) SkyNet (non Terminator fans may have to look it up)--computers from microcontrollers to Big Blue and the Dorval & Tokyo Crays all talking to each other. So far no sign of that
Trying hard to get a strategy built in PowerLanguage .Net (MC's C# extension) by market open this AM--my first MC .Net strategy.
First observations:
1. If NT C# is from Venus, MC C# is from Mars.
2. On the complete lack of documentation (by "complete lack of documentation" I mean the PowerLanguage .Net "Help" file and the IDE which is devoid of examples, explanations, Intellisense links to function definitions or even comments in sample code) I'm reminded of one of the favourite phrases of a programmer I used to manage (one in a stable of programmers, programmers very much like thoroughbred horses just much less likely to pull a muscle): "If it was hard to write it should be hard to understand."
This post deals mainly with recent work on SVM classification. An updated MC indicator (TDEMA) is attached for reasons mentioned at the end of the post
SVM Testing
Following @NJAMC's lead I've been experimenting with State Vector Machines (SVM) for pattern classification off and on for almost 2 weeks more to gain experience with the technology than to apply it to trading. So far the one issue that stands out with the Accord .Net implementation at least (as NJAMC points out) is that the time to train a feature set appears exponentially proportional to the length of the feature set as suggested by the results below for a generic 2-bar pattern recognizer mentioned in a previous post.
2 Bar Pattern Classifier Results
The test procedure was as follows:
Step 1. An MC indicator ("TD2BarrPatternPredictor2" [sic], attached in the MC .PLA and as a text file) was written to dump a chart to a data file as date/time/bar#-stamped 2-bar patterns in OHLC format normalized to the maximum high price and minimum low price of the 2 bars in the pattern.
In the example shown here a 5-minute chart for EUR.USD was dumped to a data file comprising approximately 28,000 pairs. The selected 2 Bar Pattern and "predicted bar" in the following figure ...
... becomes the following line in the dump file (ignoring the header row):
Step 2. Open Office Calc (spreadsheet) formulae were written to reconstruct the 2-bar patterns from the data as 32x32 bitmap images (a pattern of ASCII 1's and 0's in UCI's Optdigits Dataset format) as a sanity check (sample spreadsheet "EURUSD.FXCM_240__1_barPatternDataSimple2.ods" for EUR.USD 240 minute 2-bar patterns attached).
Each 32x32 bit map was divided into 2 halves, 1 half per bar, and "color coded" as follows:
........2.1 uptrend bars (close > open) print as 1's (black) on a background filled with 0's (white);
........2.2 downtrend bars print as 0's (white) on a background filled with 1's (black).
The next 2 figures show spreadsheet reconstructions of 2 patterns, the first preceding a bull bar and the second preceding a bear bar. The actual bar patterns (2-bars + "predicted" bar) as they appear on the chart are inset in the upper right of each figure. The 3rd figure below contains a screenshot of the spreadsheet itself (Open Office Calc spreadsheet attached), showing formulae used to perform the reconstruction.
2 bar pattern followed by bull bar:
2 bar pattern followed by bear bar:
Spreadsheet:
Step 3. The OHLC pair data were then converted to 32x32 bit images using a purpose built program ("SVMBarPatternClassifier", MS VS 2010 project attached).
For example, the pair mentioned in Step 1 above coded as follows:
2 Bar Pattern Classifier Run Time as a Function of Training Set Size
The run time data listed next is summarized in the plot below:
2 Bar Classifier Run Time vs Training Set Size
Parallel Processing
The Accord .Net based SVM app described here, derived directly from César's, uses fairly lengthy feature vectors (order of 1024 samples in size) and lends itself to distributed processing but more work needs to be done to achieve it. Mods made to César Souza's Handwriting SVM program included the following:
1. it was recompiled with .NET 4 and renamed (versus 3.5);
2. fields were added to the GUI to allow training and test section at run time (previously hard coded)
3. the learning algorithm was wrapped with Task.Factory.StartNew() in anticipation of progress monitoring and use of a cancellation token.
While the most recent version of the Accord .Net library appears to support .Net 4.0 multithreading via the Parallel.For wrapper for the .Run() method of MulticlassSupportVectorLearning class, César's code (and hence this code) does not seem to refer to the latest version.
Other approaches to parallel processing that come to mind include
1. CUDA (for which see the NVIDIA site and threads on nexusfi.com (formerly BMT))
2. MPI.Net and threads on nexusfi.com (formerly BMT)
My own attitude toward developing a parallel processing framework for applications in trading is mixed, somewhat jaded by 2 isolated experiences. The first in the early '90's was implementing the Biham-Kocher plain text attack on an encrypted ZIP archive across a half dozen UNIX boxes [algorithm described in the paper by Biham & Kocher, "A Known Plaintext Attack on the PKZIP Stream Cipher" still floating around on the Interwebz]. The rationale for that work was that a programmer for a company in a large Canadian city had ZIP-encrypted the company's entire accounting system and high-tailed it to Cuba with the encryption key and his daughter in tow. He was demanding a ransom for the key and the company was willing to pay something less than the ransom to anyone who could restore the accounting system in the meantime. It took 2 weeks to implement Biham & Kocher's algorithm (C language, Unix operating system) and 2 weeks computer time to crack the archive & discover the key, which turned out to be a simple alpha string--his daughter's first name concatenated to his, both of which EVERYONE INVOLVED ALREADY KNEW. [Subsequently I offered to give the code to PKWARE to keep it off the street, but when no reply was received published on sci.crypt, snippets of it turning up on ZIP crack sites for quite a while afterward]. Take-away from that episode: throwing technology at a problem may not always be the smartest approach.
The 2nd venture involved helping develop an ultra-cheap video-on-demand system aimed at the hospitality industry, its low cost to manufacture being its claim to fame IMO mainly a consequence of the design principle; namely, a distributed operating system running on a network of microcontrollers that pooled resources (including compute power) by piggybacking on the available broadband video infrastructure rather than trying to cram a supercomputer into every set top box. My responsibility was prototyping the hardware and firmware, which was based on a neural model, and then sitting behind a desk, wearing pretty clothes and taking credit for subsequent breakthroughs made by the development team who turned it into a marketable product. This distributed approach allowed for relatively high sales margins and the company prospered, was bought out. What eventually killed the company (and the work) was not so much the increasing availability of high demand content (euphemism for porn) on the Interwebz which made the walled garden basis of VOD obsolete, but a string of business types who repeatedly bought the company for its cash flow, starved R&D of funding and resold it for the price of its assets. These wheeler-dealers the sort who figure they can fake their way in business by latching on to a cash cow; or more properly perhaps a "cash goose", since they have little or no understanding of why when you cook the goose the golden eggs stop. I see one of these guys was recently arrested on murder charges after fleeing the country--character = destiny it would seem. Take away from that was--why freeeeeeking bother.
Conclusions
There are a host of issues affecting the outcome, from choosing to represent the pattern as a bitmap (which is then reduced by the classifier to a 1D array) to choosing to color the bars and background as done. These issues could be addressed in future work, if there is any. For example, an MC indicator ("TDZigZagPnts2") has been attached in the .PLA file and as text that dumps OHLC data leading up to a significant pivot high or low, in preparation for coding sequences of the sort NJAMC was working with. BTW, what the pivot dump indicator records as an SVM feature vector file need not be OHLC data--could be other metrics one finds useful for trading.
While a "hit" rate for the trained generic 2-bar pattern classifier of between 50% and 60% may mean something to a trader (if nothing else it might suggest what initial stop/profit ratios have to be to maintain Al Brook's Trader's Equation) in this context I prefer to think we could do just as well and moreover get to the Jack Daniels a whole lot sooner if we flipped a coin.
A larger training set in this case does not appear to promise any better results and run times quickly become prohibitive.
Finally, it may be worthwhile as a matter of interest isolating the "TOP 10" 2-bar reversal patterns referred to in a previous post that prompted this study, to see if they produce better classification scores than 2-bar patterns in general. I wrote a strat to detect and trade them some time ago so it's just a matter of dumping the chart instances detected in a chart to a file and running the numbers.
Other Work
I continued to trade during this time, 3 or 4 to 14 pedestrian trades/day in a variety of spot currencies but last week also one experimental sojourn into ES on paper. In addition I will do a trade in gold miner and/or oil company ETFs if a setup occurs. I seem to have passed the point a while ago discretionary trading STF spot currencies where the issue is not whether I can make money but how much I can make; i.e. what amount of risk I'm willing to bear. I'm still trading 1 or 2 contracts split into 2 to 4 targets. While issues remain, the mindset (especially the nature of confidence) is vastly different then (as a newbie) and now. Hopefully I can one day capture whatever it is that makes the method profitable in a bot. So far I've proved (over and over) as others have claimed profitability is more than a list of rules strictly adhered to.
I love the London session, which for me means going to bed early enough to get up bright eyed and bushy tailed prior to 4 AM local time. Not only are currency markets generally active it means 3 or 4 quiet, uninterrupted hours before the rest of the house stirs and I get to experience the sunrise. Good for the soul.
The danger at this point is no longer out of boredom seeing setups where they don't exist but allowing one instrument to draw required attention away from another.
I've attached an updated version of the MC indicator TDEMA (trivial to code in any other language--simply the 15EMA colour-coded for slope). The update added a second monochromatic EMA separated from the first by 1 ATR, the reason being that I wanted a trailing stop target removed from the 15EMA itself which more often than not gets penetrated during insignificant retraces. It appears the 1 ATR corresponds more or less the point in a retrace where the next higher time frame MACD slope becomes negative (for a long trade) or positive for a short trade, the slope of the next higher time frame MACD being what I tend to use to bail from a trade before targets are reached.
The 1 ATR also serves as a kind of chop indicator as can be seen in the chart below. I know chop indicators are a dime a dozen and don't work if we rely on them, but I find they can lend a little peace of mind nevertheless. I also know what price action purists think of indicators in general but bots depend on some sort of price action metrics and until I code Al Brooks MAs will have to do
What was advertised in Step 3. in the previous post as a project to convert scaled OHLC pair values to bitmaps and posted as "SVMBarPatternClassifier" is in fact the modified version of the bitmap classifier itself referred to in Step 4 of the previous post.
The correct project for Step 3 (that converts OHLC pair data to bitmaps) is attached to this post ("SVMBarPatternRecogition")