Thank you for your thoughtful and constructive reply. Would you mind posting a chart and log of the phenomenon you describe? I could speak to the situation you described of the successful (and not so successful) transference of Jack's work into a working PEP alto and trading platform. Jacks was a very clever man. There are typos and logic terraces as well as intentional designed gates. There is a way to have a breakthrough in the material but it exists in a place one has not looked. We each hold the key to our own prisons of circular thought. There is tech that can support the emotional healing process. Whether it makes the difference, we'll have to test. In refraining from saying more, I reserve the right to walk my talk. When there's some demostratable successful trading consistency to post, we'll all be happy. I'm currently scoping and bounding my understanding to the next level. This is what engaged me enough to start posting. The detail in the forward progress of OOE's has peaked my interest enough to desire to log JHM 2.0 successfully in realtime. I don't have the capacity yet, and I'm building it dtill by drill. For any further up the path, constructive feedback with respectful tone welcomed. Any ad hominem attacks will invite an ignore forever response. Any requests for trading records is premature. A successive measure of transference is to be able to call the open with positive statistical significance. I'll post artifacts of my analysis here (if that would be alright with you) Btw, are there any software platforms that degap? Any Python, SQLite programmers out there? Also is there any platforms that have a graphic trade entry tool? For example, if a sloped rtl is crossed an order gets triggered? Thank you in advance !!
There's a few issues I listed. Here's one for example yesterday morning. Sometimes price moves are clean and you get some reliable EE's, but other times the market just doesn't form full sequences of volume events to EE and you get a mess of failsafes. Automatic entries on every End Effect is going to result in a huge string of small losses. A day like this alone should lay to rest the prospect of blindly trying to follow EE's. If it was that easy we'd have seen success with this system. You need to use either discretion or additional rules to take a step back and trade the slower fractal. --- Also see the images of how things unfold in RT at times. I just replayed the first day of the month at random for some examples. #1 We're carrying over an up-trend and we get PP1 first bar. So we have EE to short and the bar is red. #2 But look, a convincing red +PRV turns IBGS by End of Bar. #3 It even breaks the Bookmark so we're looking at a loss. You can either exit intra-bar when price violates BM, or hold until EOB, and if you're going to do the latter sometimes it will come back but sooner or later you will be taking a big loss on a high range bar going against your trade. #4 Shows that even if we held to the actual EE up it's still going to be a loss, and that the End effect outputs are often divorced from the actual turning points of the trend segments. Even if we wanted to go long here the up-segment is well underway from it's actual geometric FTT on Bar 5. --- These are just a few examples I dug up quickly. The RDBMS is just too blocky and mechanical to blindly obey its "rules". I think that either some degree of intuition is required to screen out bad market conditions, cherry pick the better spots, or trade slower fractals is required. Some days it really shines when you get a single 5+ point trend segment in high pace, but a bunch of tough spots like these examples exist most other days and the system doesn't really address how to navigate them.
Thank you !! If it wouldn't be too much trouble, would you post the annotated chart snippet of the beginning of the long move from DU (what came before)? I'm out of town away from my desktop, it'll be a day or two before I have access to posting a graphic reply. Again, thank you so much !
Haven't annotated EE's for quite a while; think this is correct but there's a few obscure EE's and caveats that sometimes come into play. Don't think I missed anything but take it with a grain of salt. However, my intended point wasn't to dig into this particular example, but rather to demonstrate the fact that these occurrences happen somewhat often. The fact that this system hinges on a single tick or +/- few dozen contracts at times to specify it's output, means that there will always be some less accurate readings from time to time imo. P/V is paradigm and we are trying to look at arbitrarily spliced data slugs and read between the lines to see the sequences unfolding. Rigidity is a hindrance in an enterprise like that. So although the RDBMS is a more mechanical construct than any of the previous iterations of Jack's system, I still think the best it can ever do is to provide a framework within which to trade successfully and discern market sentiment. But no matter what version of this stuff or if Spyder or Jack was teaching it; that leap from framework to fluid execution time and again was the area that just couldn't seem to be consistently transferred despite their best efforts.
A chart type can be created in Ninjatrader (NT) that can do this but it requires a bit of advanced programming. If by 'degap' your intention is to adjust a bar such that its high or low is modified, then you are essentially creating a synthetic bar. It is doubtful that such tactics will result in desirable results. If memory serves, Spydertrader may have first proposed 'degapping.' If the reports from one seminar that he conducted in Las Vegas are accurate, then it appears that he became lukewarm towards the idea. He was a proponent of session (e.g. ETH to RTH) 'degapping' but not bar by bar. NT 8 may have this capability.
No, I was not. However the topic of 'degapping' came up often in the TL thread and what I wrote above is what was relayed by one of the posters.
The important part of JHM 1.0 is carryover channel, introduced by JH well from beginning. To draw carryover channel easily, one need to have somehow "modified" datafeed called "degap[ed | ing]" - term first time [I am not sure about this] used by Spyder during Las Vegas meeting. At that meeting, as soon as Spyder said word "degap" somebody from the audience immediately ask Spyder - "Do we need degap every intraday 5 minute bar?" - Spyder's response was something like this - "If you are degapping, you have to degap everything." [It's not exact words.] Later some folks understood this as his support to the idea of degapping every intraday bar. However, as far as I know, it was never mentioned by him any more. Instead, Spyder's work with TN team resulted in modified ES datafeed without any intraday degapping. One can explicitly request it by calling TN support. I think JH just borrow this idea by incident and never had any chance to validate usability of it. I read a lot, how JH complained that TN won't implement intraday degaping. IMHO, the intraday degapping make no sense to me whatsoever. Look on volume, ticks based ES chart, there are almost no gaps on them or they are very rare, visible only during fast moving events. Range bar chart has native 1 tick gap on every bar. Degapping ES 1 tick chart resulted in flat line. And from my experience, except The May 6, 2010, Flash Crash, it's remain to be seen 2 ticks intraday gap on ES RTH chart. Also it's good idea to keep in mind that JHM works only on high liquid markets, unaffected by any major news/events, like FOMC, stock earnings announcements, etc.
There is code (not mine) written for SierraChart. It's very inefficient(imo) on short time frame data sets of more than a week or so, but the code works well otherwise. Its been a while, but yea. Doable, but not trivial with Sierrachart. Much simpler, perhaps even trivial, with platforms supporting a .NET language where out of the box a line is an object, as opposed to creation, modification, maintenance, and deletion of user-created drawing objects as required through SierraChart ACSIL (C/C++) language.