The perfect moving average
- Thread starter aphexcoil
- Start date
Of course, you need to invert just the noise and not the signal you wish to keep. Hence the need to take a picture of pure noise. Again, probably not possible in talking about the stock market, but what the heck. For example, if you wanted to get rid of tape his in a song, you would record the first few seconds of tape before the music kicks in. That hiss would be inverted and mixed with the music once it started in hopes that the initial noise (hiss) would come close to matching the general hiss over the rest of the tape.
Echo,
That is a pretty great idea. I have cooledit and use it a lot to filter out undesirable audio. There are a lot of tools within cooledit that might be applied to a financial equivelent of time-series data.
Maybe we could call it coolfinance? lol
The next graph, when I get it done, will be really interesting.
aphie
That is a pretty great idea. I have cooledit and use it a lot to filter out undesirable audio. There are a lot of tools within cooledit that might be applied to a financial equivelent of time-series data.
Maybe we could call it coolfinance? lol
The next graph, when I get it done, will be really interesting.
aphie
aphie,
<b>Cool graphs!</b> Have you tried taking a 500-bar EMA on the first data set (the first differences of the 200-msec price averages) and overlaying that EMA (multiplied by 500) on to the second graph (the 500-bar differences).
Looking at your second graph (http://www.elitetrader.com/vb/attachment.php?s=&postid=117604) it looks to me like the velocity is jumping around quite a bit. Indeed, the 500-bar delta may be too wide to resolve the microstructure of the trend. I notice several places where the signal goes from high positive velocity to low negative velocity in only about 500 bars or so.
Also, I notice a distinct lack of stable periods of constant velocity. The presence of positive and negative-going velocity spikes is quite curious. I must say, though, that estimating the velocity looks pretty challenging to me. During that nice little mid-day rally, the ES rose a respectable 20 points in 2.5 hours. But on the 500-bar delta chart, this would only a 1/4 point offset in the measured velocity (20 pts/ 2.5 hrs = 0.0022 points/second). Seems pretty subtle to me. I'm sure there is something really exciting in all this data, its just a matter of getting a proper way to filter it or match it against some pattern recognizer.
<b>RE: Time delays in the round-trip cycle</b> I had another thought. Does the raw tick data have a timestamp for the data provider? If so, you could track the latency between this timestamp and the clock on your computer to gauge some of the round-trip delay. Fast market conditions or data storms on the internet would cause the timestamp on the data to lag further behind your computer's clock. You might also be able to gauge the time delay into your broker's systems by pinging the broker with a simple request on occasion. These two measures of the delays in the round-trip from market to you to the market may be imperfect, but I'd bet they would help you avoid trying to put-on high-speed trades when the internet, market, or broker was bogged down.
Keep up the great work,
Traden4Alpha
<b>Cool graphs!</b> Have you tried taking a 500-bar EMA on the first data set (the first differences of the 200-msec price averages) and overlaying that EMA (multiplied by 500) on to the second graph (the 500-bar differences).
Looking at your second graph (http://www.elitetrader.com/vb/attachment.php?s=&postid=117604) it looks to me like the velocity is jumping around quite a bit. Indeed, the 500-bar delta may be too wide to resolve the microstructure of the trend. I notice several places where the signal goes from high positive velocity to low negative velocity in only about 500 bars or so.
Also, I notice a distinct lack of stable periods of constant velocity. The presence of positive and negative-going velocity spikes is quite curious. I must say, though, that estimating the velocity looks pretty challenging to me. During that nice little mid-day rally, the ES rose a respectable 20 points in 2.5 hours. But on the 500-bar delta chart, this would only a 1/4 point offset in the measured velocity (20 pts/ 2.5 hrs = 0.0022 points/second). Seems pretty subtle to me. I'm sure there is something really exciting in all this data, its just a matter of getting a proper way to filter it or match it against some pattern recognizer.
<b>RE: Time delays in the round-trip cycle</b> I had another thought. Does the raw tick data have a timestamp for the data provider? If so, you could track the latency between this timestamp and the clock on your computer to gauge some of the round-trip delay. Fast market conditions or data storms on the internet would cause the timestamp on the data to lag further behind your computer's clock. You might also be able to gauge the time delay into your broker's systems by pinging the broker with a simple request on occasion. These two measures of the delays in the round-trip from market to you to the market may be imperfect, but I'd bet they would help you avoid trying to put-on high-speed trades when the internet, market, or broker was bogged down.
Keep up the great work,
Traden4Alpha
aphie and traden4alpha,
you two seem like you'd be best friends in the real world. hehe
you two seem like you'd be best friends in the real world. hehe
Traden4Alpha,
Thanks for the support. Actually, I only captured an hour's worth of market data because my program started acting up. I got a little excited and coded too many things at once and didn't double check all of them.
I put it in autotrader mode and the log file got shut off and then it started making trades on its own. The trade report came back 4 hours later and it had make 1,452 trades with an average win ratio of 0% and an average loss per trade of .25 (the spread).
Including commissions, on one contract, I would have netted around negative -$7,000 in commissions and -$18,000 in bad trades. That's not a bad return for just one contract -- if my goal was to lose as much money as fast as I possibly could.
I shut the program down and looked over the code and found out that the routine that signals "buy" or "sell" to another routine -- well, the other routine constantly checks to see if their is a buy or sell signal (every 1 millisecond) ... I forgot to code it to stop checking when in a trade ... well, you get the point -- it was very funny in retrospect. I fixed that little "glitch" though.
Also, I am going to try and push this project ahead a little faster and wrap it up and upload it here or give a link to it ... so other people can test out the simulator (if they have esignal).
Do you have esignal?
aphie
Thanks for the support. Actually, I only captured an hour's worth of market data because my program started acting up. I got a little excited and coded too many things at once and didn't double check all of them.
I put it in autotrader mode and the log file got shut off and then it started making trades on its own. The trade report came back 4 hours later and it had make 1,452 trades with an average win ratio of 0% and an average loss per trade of .25 (the spread).
Including commissions, on one contract, I would have netted around negative -$7,000 in commissions and -$18,000 in bad trades. That's not a bad return for just one contract -- if my goal was to lose as much money as fast as I possibly could.
I shut the program down and looked over the code and found out that the routine that signals "buy" or "sell" to another routine -- well, the other routine constantly checks to see if their is a buy or sell signal (every 1 millisecond) ... I forgot to code it to stop checking when in a trade ... well, you get the point -- it was very funny in retrospect. I fixed that little "glitch" though.
Also, I am going to try and push this project ahead a little faster and wrap it up and upload it here or give a link to it ... so other people can test out the simulator (if they have esignal).
Do you have esignal?
aphie
smokey_mcPaat
Guest
well, i didnt take the time to read this entire thread- i think alot of TA is crap (but, thats just me- if it works for you- great) but don't ever think that there is some "perfect" system for trading- the only certain thing in the markets is........
aphie,
<b>RE: 1,452 trades with an average win ratio of 0% and an average loss per trade of .25 (the spread)</b> LOL! Sounds like you found the Holy Grail system for the broker. Hmmm.... maybe some less-than honest Prop Firm will buy your system to give to their chumps.. errr ummmm I'm mean traders. Anyhoo, debugging code is always fun -- its a never-ending cycle of confusion, insight, and embarrassment.
<b>RE: eSignal</b> No, I don't use eSignal or any real-time dataservice because I do not trade intraday. I prefer EOD trading myself -- lets me spend the day doing system development (or spend too much time on ET
). But, if I had a reliable intraday automated trading system, I would not hesitate to use it (I guess some of the wittier wags on ET would retort that "reliable intraday automated trading system" is an oxymoron).
Cheers,
Traden4Alpha
<b>RE: 1,452 trades with an average win ratio of 0% and an average loss per trade of .25 (the spread)</b> LOL! Sounds like you found the Holy Grail system for the broker. Hmmm.... maybe some less-than honest Prop Firm will buy your system to give to their chumps.. errr ummmm I'm mean traders. Anyhoo, debugging code is always fun -- its a never-ending cycle of confusion, insight, and embarrassment.
<b>RE: eSignal</b> No, I don't use eSignal or any real-time dataservice because I do not trade intraday. I prefer EOD trading myself -- lets me spend the day doing system development (or spend too much time on ET
). But, if I had a reliable intraday automated trading system, I would not hesitate to use it (I guess some of the wittier wags on ET would retort that "reliable intraday automated trading system" is an oxymoron).Cheers,
Traden4Alpha