Systematic trading | Page 47 | Forex Factory

Options

Go to
Permalinks
Print Thread

Similar Threads

Trade another day through Systematic Trading 203 replies

Nonparametric Association Measures in Systematic Trading 57 replies

Anyone use Systematic from Alpari? 1 reply

A Systematic Approach to Markets 68 replies

Systematic Trading vs. Discretionary Trading 14 replies

Attachments: Systematic trading
Exit Attachments

Systematic trading

  • #921
  • Jun 8, 2010 3:32pm Jun 8, 2010 3:32pm
Quoting ForexQuant
I suggest to use skewness beside all these performance parameter. If your result is negative skew then you may easily overestimate your performance and subject to the black swan risk.
Can you elaborate?
The breaking of a wave cannot explain the whole sea.
  • #922
  • Jun 8, 2010 5:42pm Jun 8, 2010 5:42pm
Quoting mikkom
What kind of series are you using? I have been thinking if my series are too fine-grained and if hourly or daily series would be better.

p/l correlation might be something I might try too, but I'm not sure if I want strategies with negative correlation to my overall curve
I use daily series because I do not so many strategies like what you did in your backtest. Btw your backtest is awesome! That truly shows the power of portfolio construction!

But why not negative correlation? As suggested by modern portfolio theory the portfolio variance http://upload.wikimedia.org/math/4/9...eaad45f638.png is much much lower if you have negative correlation among the strategies. (ρAB < 0)
  • #923
  • Jun 8, 2010 5:48pm Jun 8, 2010 5:48pm
Quoting Craig
Can you elaborate?
I believe Taleb can explain his idea much better than me. http://www.edge.org/3rd_culture/tale...b08_index.html
  • #924
  • Jun 8, 2010 6:26pm Jun 8, 2010 6:26pm
Here is the example of the profit distribution for my portfolio. It is heavily skew to the right therefore it has a thin left tail but fat right tail.

So I could lose often but the magnitude is under control. However when I win I could win very big, just the magnitude and frequency of win cannot be measured accurately (Not even close) because the impact of rare event is unmeasurable, according to Taleb.
Attached Image
  • #925
  • Jun 8, 2010 6:33pm Jun 8, 2010 6:33pm
Here is another journal from Taleb pertaining to the skewness.
Attached File(s)
File Type: pdf bleedblowup.pdf   115 KB | 1,031 downloads
  • #926
  • Jun 8, 2010 11:58pm Jun 8, 2010 11:58pm
Quoting ForexQuant
But why not negative correlation? As suggested by modern portfolio theory the portfolio variance http://upload.wikimedia.org/math/4/9...eaad45f638.png is much much lower if you have negative correlation among the strategies. (ρAB < 0)
Basically the curve with most negative correlation to good profit curve is opposite to that (per pearson that is)

The real results of course depend on how the calculation is implemented so that's why the smiley at the end of that sentence - it was mostly a bad joke.
  • #927
  • Jun 9, 2010 9:58am Jun 9, 2010 9:58am
Quoting spekkiefx
I was just wandering what others are doing concerning time used in the ats.

Anyone using gmt? Or does anyone adjust it to BST (GMT+1 -British Summer Time)for the London session (And adjust it for the US session)? I am not sure what is best any opinions?
I keep all in UTC time.
__Thanks__ MJ
  • #928
  • Jun 9, 2010 4:54pm Jun 9, 2010 4:54pm
I know I said I will not post here anymore. I gave it a little thought and I will just not disclose anymore edge improving techniques/papers since it seems that there isn't enough money for everybody in the FX market

There are performance measurement techniques which don't assume anything about the distribution of returns, thus are more robust against fat tails. Some variations assign different weights to positive versus negative returns, and especially for clusterings of returns.

On the data storage issue, I think it's best to keep everything in UTC, just like it's best to keep everything in Unicode when working with multi-language strings. It's easy then to convert it to anything you may like. It also simplifies data handling and reduces the possibility for errors.

BTW, NinjaTrader 7 has a really cool delta-encoding tick/bar storage scheme. I was able to reverse-engineer it and now I've implemented something similar for me. Now I can store 100 mil EUR/USD Dukascopy ticks in 200 MB, just as before, but now everything is in a single day-indexed file, and it takes 1 sec after loading it from disk to go through it and output all the ticks. My previous scheme took much longer, since it had to first decompress the data. And since the file it's small, it will be kept in the OS disk cache and on subsequent runs you won't even have to wait for the initial disk load.
  • #929
  • Jun 9, 2010 4:58pm Jun 9, 2010 4:58pm
Quoting Adal
I know I said I will not post here anymore. I gave it a little thought and I will just not disclose anymore edge improving techniques/papers since it seems that there isn't enough money for everybody in the FX market

There are performance measurement techniques which don't assume anything about the distribution of returns, thus are more robust against fat tails. Some variations assign different weights to positive versus negative returns, and especially for clusterings of returns.

On the data storage issue, I think it's best to keep everything...
Just a word of advice, spending all your time getting some tick data to load a bit faster maybe the wrong place to focus. If you can load 1 million ticks in 20 secs but haven't got a profitable system then its not really going to help.
Economists have forecast 9 out of the last 5 recessions
  • #930
  • Jun 9, 2010 5:25pm Jun 9, 2010 5:25pm
Quoting markmm
Just a word of advice, spending all your time getting some tick data to load a bit faster maybe the wrong place to focus. If you can load 1 million ticks in 20 secs but haven't got a profitable system then its not really going to help.
I fully agree with you. I did the delta-encoding scheme since it took too much before (minutes). The speed is nice since I want to simulate always with full tick data, just like the real system will trade. I tried to use RightEdge instead of writing my own backtester, but it failed to handle even one full year of 1 min candles and the charting it has in incredibly slow and limited.
  • #931
  • Edited 5:48pm Jun 9, 2010 5:38pm | Edited 5:48pm
Quoting Adal

On the data storage issue, I think it's best to keep everything in UTC, just like it's best to keep everything in Unicode when working with multi-language strings. It's easy then to convert it to anything you may like. It also simplifies data handling and reduces the possibility for errors.
Adal,

I am not talking about storage. I am talking about usage of what "time" within a system. Logically I would say that for trading within London session it would be according to gmt and bst when summertime. Same for japan and us using their timezone including summertime adjustment.
I am doing some research(granted not scientific) but it isn't really conclusive. Anyone else explored this avenue?
  • #932
  • Jun 9, 2010 5:53pm Jun 9, 2010 5:53pm
Quoting spekkiefx
Adal,

I am not talking about storage. I am talking about usage of what "time" within a system. Logically I would say that for trading within London session it would be according to gmt and bst when summertime. Same for japan and us using their timezone including summertime adjustment.
I am doing some research(granted not scientific) but it isn't really conclusive. Anyone else explored this avenue?
Currently I trade as UTC. Like I said, my future system will use non-linear time frames, and these take into account uniform DST, localized DST (there is a week in each year when EU is on DST, but US not) and even local bank holidays (ie: London is on holiday, but NY and Tokyo not).
  • #933
  • Jun 10, 2010 2:56am Jun 10, 2010 2:56am
Quoting Adal
I fully agree with you. I did the delta-encoding scheme since it took too much before (minutes). The speed is nice since I want to simulate always with full tick data, just like the real system will trade. I tried to use RightEdge instead of writing my own backtester, but it failed to handle even one full year of 1 min candles and the charting it has in incredibly slow and limited.

I plan to load straight from Disk leaving the ticks in the bin format (Dukascopy) rather than storing them into a DB.
Economists have forecast 9 out of the last 5 recessions
  • #934
  • Jun 10, 2010 3:13am Jun 10, 2010 3:13am
Quoting markmm
I plan to load straight from Disk leaving the ticks in the bin format (Dukascopy) rather than storing them into a DB.
It's a good idea to store all data in a db and use binary cache(s) for simulation / backtesting.
Keeping ticks or bars in a db allows you make use of SQL and built-in procedures to easily gather various - even the most complex - data statistics. It's really amazing how powerful db engines nowadays are.
The advantage of having caches (possibly self-updating ones) is obvious though - as already mentioned - it's an optimisation to be applied when you've got profitable strategies.
  • #935
  • Jun 10, 2010 3:49am Jun 10, 2010 3:49am
Quoting Ipso
It's a good idea to store all data in a db and use binary cache(s) for simulation / backtesting.
Keeping ticks or bars in a db allows you make use of SQL and built-in procedures to easily gather various - even the most complex - data statistics. It's really amazing how powerful db engines nowadays are.
The advantage of having caches (possibly self-updating ones) is obvious though - as already mentioned - it's an optimisation to be applied when you've got profitable strategies.
Nah its not needed for tick data, storing the results of your back tests in the database for analysis with SQL makes sense, but not price data, there is the reason most chart software store price data in files and not databases.
Economists have forecast 9 out of the last 5 recessions
  • #936
  • Jun 10, 2010 4:09am Jun 10, 2010 4:09am
Quoting markmm
Nah its not needed for tick data, storing the results of your back tests in the database for analysis with SQL makes sense, but not price data, there is the reason most chart software store price data in files and not databases.
Sorry, I should've mentioned I meant professional solutions. Most chart software is aimed at people who barely need to do any systematic price analysis and that's why there are no facilities like an sql-based db engine, not because it's not needed. Isn't it partly why we end up seeking alternatives or implementing our own tools?
  • #937
  • Jun 10, 2010 4:30am Jun 10, 2010 4:30am
Quoting Ipso
Sorry, I should've mentioned I meant professional solutions. Most chart software is aimed at people who barely need to do any systematic price analysis and that's why there are no facilities like an sql-based db engine, not because it's not needed. Isn't it partly why we end up seeking alternatives or implementing our own tools?
Im not sure I could implement a strategy in SQL, im sure it can be done, but im not a guru so I need to use other tools. However if all you are doing is loading the data into an external system for analysis then its not needed, and causes bloat. To be honest it all depends on the needs of your system, I think both ways are valid.
Economists have forecast 9 out of the last 5 recessions
  • #938
  • Jun 10, 2010 7:12am Jun 10, 2010 7:12am
Quoting markmm
Im not sure I could implement a strategy in SQL, im sure it can be done, but im not a guru so I need to use other tools. However if all you are doing is loading the data into an external system for analysis then its not needed, and causes bloat. To be honest it all depends on the needs of your system, I think both ways are valid.
It's not about programming strategies with sql, it's mining.

Data mining of large amounts of data is much easier (and faster) with database than it would be with raw data, especially in situations where the data amount is very large.

I have data both in raw disk binary and database for that exact reason, it's also much easier to do random checks to data this way, random example - what is the weekday with highest average volatility of all markets combined, time between 18:00-23:00 including only those prices that are higher than yesterdays close. With sql I'm done in 20 seconds with my query, with almost any programming language... well it's going to take time.
  • #939
  • Edited 7:26am Jun 10, 2010 7:16am | Edited 7:26am
Quoting mikkom
It's not about programming strategies with sql, it's mining.

Data mining of large amounts of data is much easier (and faster) with database than it would be with raw data, especially in situations where the data amount is very large.

I have data both in raw disk binary and database for that exact reason, it's also much easier to do random checks to data this way, random example - what is the average volatility of all markets on wednesdays 18:00-23:00 for those prioces that are higher than yesterdays close. With sql I'm done in 20 seconds,...
You still have to go through all weekdays, how is that random check? Each to their own, I find SQL painful to use for anything complex I can use linq and C# (thanks spekkie) collections to do the same.
Economists have forecast 9 out of the last 5 recessions
  • #940
  • Edited 7:24am Jun 10, 2010 7:22am | Edited 7:24am
Quoting mikkom
I have data both in raw disk binary and database for that exact reason, it's also much easier to do random checks to data this way, random example - what is the average volatility of all markets on wednesdays 18:00-23:00 for those prioces that are higher than yesterdays close. With sql I'm done in 20 seconds with my query, with almost any programming language... well it's going to take time.
I don't think such type of analysis can work anymore. The market have changed a lot. Investors and the way they react has also changed a lot. Analysis would work some time ago, but not anymore. Worries over the exit from the recession have made them mainly look into short term profit. If your analysis work for one day, it won't work for many others.

...and there are many more to change. Everything. Maybe this summer, maybe a little later.
0 traders viewing now