A common mistake is to make implementation decisions or parameter choices based on "what improves the summary performance of a backtest".
Quant research is not "changing random stuff and picking the best performing backtest"
1/n
Quant research is not "changing random stuff and picking the best performing backtest"
1/n
https://twitter.com/macrocephalopod/status/1382299510945284100
A backtest is a very complicated thing.
In the best case, the cause -> effect relationship between what you are changing and the performance of the backtest (say) is highly non-linear.
More likely there is no clear relationship.
2/n
In the best case, the cause -> effect relationship between what you are changing and the performance of the backtest (say) is highly non-linear.
More likely there is no clear relationship.
2/n
Quant trading is not "changing stuff until you get a backtest you're happy with".
You need to split what you're doing into small component chunks and model those chunks as best you can.
3/n
You need to split what you're doing into small component chunks and model those chunks as best you can.
3/n
Say you find that an effect you are trying to harness is positively correlated to volatility.
Your choice on how to forecast volatility should be based on *what forecasts volatility most effectively* over the timescale you are making trading decisions.
4/n
Your choice on how to forecast volatility should be based on *what forecasts volatility most effectively* over the timescale you are making trading decisions.
4/n
NOT what gives the best summary backtest - because that's a super complicated process you can't reason about.
Chunk down. Model the bits carefully. Pick parameters based on what each chunk is trying to achieve.
Don't just change random things and pick the glory backtest
5/5
Chunk down. Model the bits carefully. Pick parameters based on what each chunk is trying to achieve.
Don't just change random things and pick the glory backtest
5/5
• • •
Missing some Tweet in this thread? You can try to
force a refresh
