DEFINITELY Here is the chart. I began to degap each time it's required. The thing is that I'm not sure about what is the requirement for degap. So far, I think we are to degap when the the close of bar n and the open of bar n+1 do not match, so when there's a gap between. Along what I've read, I've not found something clear that explain if what I say here is true. I continue to search anyway even though I think I've read the answer already. It's maybe me. I don't know. If what I say here about degapping is true, then what I think is that when the gap appears, there is to mentally move the n+1 bar to make its open match with n bar's close. It can either make or not change the price case. Example : on bar 33, 12:40pm. Without degapping action, we have XR. After the degapping action I describe, we finally have StR. And it changes a lot what will be next. Thus, is there to annotate the "non degapped price case" on the log, on the "after degap price case" ? That's a question I don't see better answer to than knowing clearly the requirement for degap. In addition to that, if the way I do degap is correct, logically the "moving" of bar n+1 should be "conserved" when comparing it to bar n+2. And this creates a cascading effect. Something more that causes me troubles : Reset means restart, begin again from start. What's start in volume OOE ? : P1. If one is to reset the volume OOE each time a FS or an EE appears, is there then to assign P1 to the current bar ? or the next bar that will come, whatever path it will do ? Instinctively, I assigned P1 on each bar there is an EE or FS. If this is correct and true, then it makes, on this chart, the VTP quite unable to develop itself, as there are plenty of EE (I don't even count those that are here and I probably did not see ^^) that reset all the time the OOE. After 3 hours of logged bars on the chart, A band only appear one time. Although I know I'm not integrating everything (modrian, move reversal etc) and this will change a lot what is on the log that follows, I don't feel really meaningful the way I understood "Whenever a FS or an EE occurs, the OOE resets for a new trend segment is underway".
Now that you are understanding degapping, (which when considered on a granular level as removing the Bid/Ask spread during an arbitrary time slice), keep training your mind to adjust the price cases to their new relative position. Some think of it as moving the current bar others think of it as moving all the past bars in unison. Both are relatively the same in effect. The nuance is the accuracy of the actual price of the current bars OHLC, which then becomes a philosophical loop. This affects one’s approach on how they code software to support the concept of degapping and the work required to do so. Sometimes one has to add-on and other times one has to take-away to achieve clarity. In terms of your operating point in the annotated chart, the way you perceive the FS is at times not allowing a T1 to develop. To clarify this consider that the price cases that you are annotating as the fastest fractal on the 5m can be considered trend segments of a larger fractal container. This next larger container assembles these Price case trend segments into D-nD-D traverses (if it is actually presenting) of the larger container. This larger fractal container has it’s own trendlines that can fan or accelerate as per ‘the rubber meets the road thread’ Just focus on composing the next larger fractal and not getting carried away in nesting larger and larger fractals even though they can be true. For this is the part where one can ‘jump fractals.’ Just be diligent as you are and keep building from the basic granularity on up. In the literature it states clearly which bands have a P1 on the n bar and which ones have it on the n+1 bar. If a P1 is assigned then a new trend segment is underway and the progression of the OOE is T1 as long as the volume bar is in actuality decreasing relative to the P1. To support this nuance in perception use the right hand side of the ‘additional notes’ column or create a new column that logs an assigned P1 distinct from a P1 that is part of a previous OOE. Depending on the band, some rows in the log will have both on one row and other rows will have an assigned P1 on the n+1 row.
Here is the end of the chart fully logged. I conserved the way I understood things, and will refine it from that.
Thank you very much, this is very helpful. It was what I sensed quite instinctively. If a price bar is degapped from prior one, then you must compare the next bar to the "moved position" of the prior one. Aha -> then by cascading effect, almost every bar will be degapped because any degapping required action will surely destabilize the following next bars...until it matches another degapping/no degapping, adjusting it all. Wow, that is true beauty.. I have at the moment in mind : assign P1 on current bar for FS and A-band EEs, on all other EEs, P1 is on the next bar. All other EE must be equal then to PP!s and B+C-bands EEs. Let's refine my log/chart from that. Plus, I'm maybe wrong and there's nothing bad with that, but while readin your last post @Sprout , I feel like the answer you provided is peripheric to what I asked about : "when a bar is degapped, are we to label the price case in function of the new degapped ubication of the bar ?". And being peripheric to this question, I don't know why but I feel like I have th answer now : NO, don't label price case from the degapped ubication of bars, BUT label price case as they appear on the chart whithout degapping action. This phenomenom (getting an answer from a derived answered question) begins to be usual while I read your posts @Sprout , and this reminds me with delight the time when I was progressing on a table (tablesoccer) by not playing on it but playing on an other one. There are different official tables in the world, 5 to be exact, and they all share both similarities and differences that exclude some things doable on other ones. Almost everything is doable on any table, but you must do it slightly differently from a table to another, if you want to get to the same result (gesture, move, pass, shot etc) with a more or less important degree of distortion. To get to the same, you'll have to add or remove a little detail that makes it possible. It takes me to : Finally : Not going rigidly straight, but like sailing a curve ? Wish you a perfect full offer of the market extraction today
Earlier in the day when I was reading what you said @Sprout about degapping, and while I was writing about it, things appeared clear to me. It's not that clear now. Why so ? - you said I understand this nicely. But once I degap mentally, I only see bar by bar the gap increasing or decreasing, I imagine the prior bar at its new position...and what I see is that if I stick the open to prior bar's close : - for example at 12:05pm so bar 32, the degapping is aligned. No degap is required. The requirement comes back again on next bar. If I move the open of 32th bar to stick it to bar 32's close, my brain makes tells me : - you can either just take the 32th open and stick it to prior close - you can either take the entire bar and move it to make it match with prior close. If I do so, the price case that appear would be then, in this example, a StR. It changes everything. And this takes me to what I said in my prior post when I said : - you can either take the bar and extend its low as you bring it upward -... A bit lost here. I understand the concept of degapping, but I don't understand yet the effect it has on the log. Need a break, here is the first part of the 3rd refining of 03/27/19 chart.
Most likely you are making it more complicated than it is. There's annotating a chart where one degaps bar-by-bar and logging the resulting price cases from doing so. and There's annotating a chart where one does not degap and logging the resulting price cases from not doing so. Both are distinct logs from each other. That's why there is a column on the log to record that the process per bar, if it was required or not, was performed or not. As for the difference between moving the n bar to degap or whether one moves the prior (n-1) bar, if moving the prior bar, all pre-prior bars would have to move as well (n-2,n-3,n-4, etc.) This makes a difference when one attempts to code in software a re-drawn gapless chart. It makes no difference when mentally de-gapping since one is degapping the n bar relative to the n-1 bar. RDBMS is not focused on the absolute price, only the relative price so as to gate or permit the measure of volume.
Yes this is what I wanna do. As quite often ^^ Ok let's then have an example : Bar 2 : absolute price case = FTP, no degap, no permission to measure volume, wait Bar 3 : absolute price case = XB, no degap, permission to measure volume. Bar 4 : absolute price case = XB, degap, it's bar n, we move it of one tick (one square on the sheet) to make its open match n-1 bar's close so bar 3's close. Bar 5 : absolute price case = XB, relative price case = FTP, there is no gap anymore being as the open of this bar was already up-gapped compared to bar 4's close. If Bar 5's open was matching with bar 4's close, the degapping action would have continued. So in the log, on bar 5, is the "Price Case" column te be filled with FTP ? Or simply XB with the cross into "Degap/UL" column to remind there was a degap ? What you said above leads me to say : -> If RDBMS focuses on relative price cases, logically I should put FTP on bar 5 and then not measure volume, whereas originally we would have had to do so. Do you agree with all this ? Am I ok and not complicating it anymore ? Or don't I get it yet ? While the conditions match to let you answer me, I'll refine my log (03/27/19) from the baseline I have now. Best day to you !
Beginning to refine the log with relative price cases, I see a first deduction as a cascading effect : Absolutely, bar 4 is a BMrev, BUT, relatively after degapping, it is not, as bar 4 requires degap and then by going up of 1 tick, the close is on the BM which is not a BM. So, as a cascading effect, there is no BMrev on Bar 4, then no P1 assign and volume OOE can progress forward and I get T1.
Maybe I'm understanding a bit better now. Bar 4 needed a degap. It does not change the price case, so to speak absolute price case between bar 4 and bar 5 is the same as the relative one, resulting from the degapping of bar 4. So, I guess on bar 5 there is no degap to put in the column of the log, and the relative price case on bar 5 is intact compared to its absolute : XB. Let's see how it progresses
Tiny Aha -> the degapping action makes understand quite a lot about the importance of the number and length of each leg of each bar.