Quote from RoughTrader:
...
Code is the baseline by which the technology is implemented. It is not the single representation of core ideas and algorithms.
My coding style is unique to myself and would be useful to others in only a limited extent.
My desire is to organize the rules from the pool of knowledge. Once I have reached a satisfactory milestone, I am happy to discuss "methods" by which I have organized the Hershey method into quantitative modules. I suppose the closest thing you could compare this to is "pseudocode".
Please remember, my journey is to "go beyond the hype" of this method and find out for myself whether this thing can be captured in backtest. That being said, I will quickly dismiss both cheerleaders and disgruntled pessimists. I am only interested in garnering facts and rules, and reporting back to everyone who participates in this thread. If you don't feel like chipping in, that's cool. But if / when I return with some demonstrated results, good or bad, I think people will raise more than an eyebrow or two and open the way for more discussion.
This is not about protecting intellectual property. It is about organizing this system and reporting back to you how I have organized it.
RoughTrader
RoughTrader,
Ok, this is good enough for me as I would be more interested in ideas, algorithms, "pseudo-code", etc as opposed to code that I would prolly re-write or an app that I couldn't modify. Although, I do understand the others point of view on this.
I've been studying the method for a while and have written some tools specifically geared towards the method. FWIW, I'll throw out some ideas and opinions for you to consider.
Regarding channels, I think it's cool you're working on auto-channels but it wouldn't be the approach I would take. I would semi-automate them. Why?
1) While drawing channels can be somewhat mechanical, there are times when experience and discretion come into play. If one draws every mechanical channel, it is my opinion that a certain percentage of them look "ok" but are out of context. Note: I'm all for things being mechanical.
2) Dealing with carry-over (CO) channels from previous day(s) prolly adds more complexity. If you leave out the CO's and don't account for the previous sentiment, your context can be wrong right off the bat. For example, a mechanically drawn dominant traverse is actually a non-dominant retrace.
3) Have you tried to trade mechanically drawn channels at the Forest or traverse level? It is my opinion that one must consider more than channels to base decisions. IMHO, the "interesting" part of this stuff is being able to quantify Change and Continuation (CHG/NOC). Being able to determine CHG/NOC as price approaches the RTL is more important than price breaching the RTL, again, IMO.
I believe once you have a good handle on the method, you'll see how important CHG/NOC is, and the need to be able to quantify CHG/NOC on multiple fractals.
I would code up a channel "object" that is intially drawn from 3 handrawn points (1, 2, 3). These objects could be intraday or span multiple days. Once instantiated, I would make try to make the object smart enough to handle volatility expansion (prolly easy) and channel "widening". The widening part is intersesting. To do this, one needs to at least look at volume from a Gaussian point of view or a quantifiable method (not pattern recognition) to measure increasing/decreasing dominant/non-dominant volume. I've have some ideas on this that may or may not be worth anything.
Anyway, I'm definitely not trying to discourage what you're doing, I'm just throwing a few things out there for you to think about.
Regardless, best of luck with your app,
spooz