Support Board
Date/Time: Tue, 22 Apr 2025 15:25:05 +0000
Post From: Annoying problem with Heiken Ashi and ACSIL (for SC engineer)
| [2025-01-09 16:05:33] |
| BenjFlame - Posts: 337 |
|
Turns out the problem was completely different than what I thought. Here is the explanation, thanks to OpenAI o1 model: Short Answer Yes, there is indeed a subtle logic flaw: you are relying on sc.Index - 1 or sc.Index - 2 to refer to the “entry bar” or a specific prior bar, but in reality you are in an autoloop study where Sierra Chart itself advances sc.Index in ways that don’t always match “the bar of entry ± 1.” As soon as a new bar starts, or if your study is processing partial bars, you can end up referencing a bar or two further ahead (or behind) than intended. Simply put, “bar since entry = 1” does not guarantee that the entry occurred precisely at [sc.Index - 1]. Why This Happens 1.Autoloop Behavior in Sierra Chart When you use sc.AutoLoop = 1, Sierra Chart calls your function “once per bar” (sometimes more if a bar is still forming). This means sc.Index increments automatically as new bars form, but can also temporarily point to earlier bars during chart reload or partial updates. 2.Timing of Orders vs. Bar Index -You might place an order in the middle of the current bar (intrabar). Then, at the close of that bar, sc.GetBarsSinceLastTradeOrderEntry() will become 1. -Because of partial updates (e.g., ticks inside a bar), your code might run more than once, and sc.Index might increment from intrabar updates. By the time your condition sees “bars since entry = 1,” you might actually be on bar sc.Index that is one or two bars ahead of what you assume if we only think in full bars. 3.Referencing sc.BaseData with (sc.Index - X) -You assume that “the bar of the entry” is [sc.Index - 1] or [sc.Index - 2]. But if an intrabar update has advanced sc.Index, then [sc.Index - 2] could actually be the same bar in which you placed the order, or it could be another bar entirely. -Likewise, once you switch from -2 to -1 or vice versa, the logs about “previous bar highs/lows” change in ways that you don’t expect because Sierra Chart is counting bars differently under the hood. In short, your code is mixing “bars since entry” with “sc.Index - some offset,” but these two concepts do not always line up one-to-one. How to Fix or Work Around It A robust approach is to store the bar index at the time the order is placed, and then reference that stored index explicitly later. For example: When you actually submit the trade, record the bar index: int MyEntryBarIndex = sc.Index; In subsequent bars, if you want the low of the bar right before the entry bar, you can do: float priorBarLow = sc.BaseData[SC_LOW][MyEntryBarIndex - 1];
Or if you want one or two bars after the entry bar, use: float barAfterEntryLow = sc.BaseData[SC_LOW][MyEntryBarIndex + 1];
float barTwoAfterEntryLow = sc.BaseData[SC_LOW][MyEntryBarIndex + 2]; Use your stored index in any conditionals (e.g., for the “aggressive scratch” logic), instead of relying on “sc.Index - 1” or “sc.Index - 2.” This way, you know exactly which bar you’re referencing, regardless of how Sierra Chart’s autoloop or partial updates advance sc.Index. Key Takeaways 1.“Bars since entry = 1” means the study is running on the first bar after the entry bar has fully closed. It does not necessarily mean the current loop’s “sc.Index - 1” is the entry bar. 2.Storing the entry bar index when a trade is placed is safer than referencing “sc.Index - X”. Logged highs/lows differ when you switch from “-2” to “-1” because sc.Index can be one or two bars ahead of your assumption—especially with intrabar updates. 3.By decoupling “bars since entry” from your direct array indexing (“sc.Index - something”), you’ll avoid the shifting references and you will observe consistent high/low logs for the bar(s) you actually want. Indeed, storing the index of entry bar at moment of entry in persistent variable, and using it to reference bars from entry bar solutionned the problem. Date Time Of Last Edit: 2025-01-09 16:11:57
|