Wish I could get the poll option to work, but I say 1. No more, no less. This will allow maximum flexibility in designing and optimizing other parameters with the ability to mathematically differentiate what is and is not a trading opportunity with a consistent standard. Any other parameters will be optimizable, but that one will have to be the "cornerstone" of the Grail. It's "line in the sand".
Hard-coded parameters or not, the algo itself is already a huge anchor ... I'd say from a flexibility point of view, you should have all parameters accessible & modifiable, with proper default value. A related question is: "identical parameters values for distinct markets, or individual (ie. optimized) parameters values specific to each market". My current answer goes to "individual parameters values", because each market truly has its own character ... this is certainly true for intraday trading, it might not be for swing/position trading ?
Yes, the 1 hard-coded parameter would be what gives the anchor it's "weight". It's the Higgs boson of the algo. I am finding a discrepancy in the optimized individual parameter values in markets as I expand my circle of markets traded. A trigger that would I'd consider unusable on the ES and filter out is perfectly fine (and even better than average) on Crude, to take my most relevant example. Same model, but different outcomes. So while the theoretically correct answer might be no, don't optimize by market, because the use of optimized values for each market is premature without knowing the future distribution of trades for those markets where the parameter value is outside the optimized range, the practical thing is to filter those trades outside the range at least until the combined historical record of those trades generates positive expectancy (with the flip side of that being to remove those trades which look promising to start, but fail to work out of sample in real trading). Keep them on the sidelines until they can prove their value. And even then, only trade them with a minimal position. That's my approach. However, I have found that once a set of parameter values fails to generate positive expectancy, it never really comes back to do so, although there can be some spectacular trades within those sets of trades. I had a ~$6 win on Crude get filtered out a couple weeks ago, for example, but primarily because an earlier trade of that "type" had generated an ~$12 loss, so why would I take it? Again, though, this could just be that the sequence of trades I'm experiencing is not conducive to positive expectancy from those parameter values at this time, but will be at some point in the future.
Hardly. I'm putting forward a hypothesis based on the idea that the most important objective of a system is to provide a trader with an objective way of identifying an "all other things being equal" context for trades. Having a single hard-coded parameter is the optimal way to do that, so that everything else going on in the market is subordinated to that one condition. From there, you can and probably should add other parameters, but you will have far more flexibility in their values. In fact, if you have ever studied software design, you will know that a principle of robust design is that the fewer hard-coded parameters, the more robust the design. I'm applying that same principle to trading system design.
IMO that's putting things backwards. The selection of the algo - which buries more assumptions than does adding any number of parameters - is the higgs boson of the algo. That's backwards, too. The more "hard coded" parameters there are, the easier it is to validate any given piece of software, all else being equal, as there are that many fewer degrees of freedom to worry about.
If it's the "ultimate" algorithm, it isn't really burying any assumptions, is it? It's a reflection of market reality. That's odd that you say you want more hard-coding because when I was writing code in the early 2000's, I was always told not to hard code anything unless it was absolutely necessary. You would give the end user opportunities to enter the necessary parameter values, rather than trying to anticipate them in advance. You would do error-checking to validate that the values were proper for the application, but that is different from hard-coding values.
I'm learning this stuff so this is a genuine question not meaning to challenge: I read everywhere else that having too many parameters tends to lead to over-fitting models. How would you reconcile your theory with that?