Support Board
Date/Time: Sat, 21 Dec 2024 17:42:34 +0000
[Locked] - Problem with Auto Recalculation
View Count: 2024
| [2015-02-23 17:55:25] |
| Richard Novak - Posts: 24 |
|
Hello, I've developed an automated trading system study using ASCIL and I'm having a problem with one of my subgraphs. The subgraph I'm having a problem with is used to store the trend state and is based on data from several longer term charts. What appears to be happening is that a full recalculation of the chart containing the study is occurring anytime the data in one of the referenced charts changes. This full recalculation is causing the trend state for bars already completed to be reevaluated and assigned a value based on the current indicator values from the longer term charts. The trend state for previously completed bars is being overwritten. Is there anyway to disable this auto recalculation? I'd prefer not to do this since I'm directly referencing the longer term charts and do not need to be notified when there is a change in one of the referenced charts. If the auto recalculation can't be disabled, it there any other way to get around this problem? Thank you, Richard |
| [2015-02-23 19:05:40] |
| |
|
Not sure why a full recalculation would be occurring. If that is happening the Window >> Show/Hide Message Log will indicate this when it happens. Does it?
Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service: Sierra Chart Teton Futures Order Routing |
| [2015-02-23 19:22:03] |
| Richard Novak - Posts: 24 |
|
Hello, Yes a full recalculation is being performed. A portion of the log output is shown below: Chart #1 is performing a full recalculation because it has been tagged. Chartbook: LS Crude Base.cht | 2015-02-23 14:18:21 Chart #6 has tagged chart #1 for full recalculation. Chartbook: LS Crude Base.cht | 2015-02-23 14:18:27 Chart #1 is performing a full recalculation because it has been tagged. Chartbook: LS Crude Base.cht | 2015-02-23 14:18:27 Chart #5 has tagged chart #1 for full recalculation. Chartbook: LS Crude Base.cht | 2015-02-23 14:18:28 Chart #4 has tagged chart #1 for full recalculation. Chartbook: LS Crude Base.cht | 2015-02-23 14:18:28 Chart #1 is performing a full recalculation because it has been tagged. Chartbook: LS Crude Base.cht | 2015-02-23 14:18:29 Chart #6 has tagged chart #1 for full recalculation. Chartbook: LS Crude Base.cht | 2015-02-23 14:18:33 Chart #1 is performing a full recalculation because it has been tagged. Chartbook: LS Crude Base.cht | 2015-02-23 14:18:34 Chart #6 has tagged chart #1 for full recalculation. Chartbook: LS Crude Base.cht | 2015-02-23 14:18:42 Chart #1 is performing a full recalculation because it has been tagged. Chartbook: LS Crude Base.cht | 2015-02-23 14:18:42 Chart #5 has tagged chart #1 for full recalculation. Chartbook: LS Crude Base.cht | 2015-02-23 14:18:44 Chart #4 has tagged chart #1 for full recalculation. Chartbook: LS Crude Base.cht | 2015-02-23 14:18:44 Chart #1 is performing a full recalculation because it has been tagged. Chartbook: LS Crude Base.cht | 2015-02-23 14:18:45 Chart #6 has tagged chart #1 for full recalculation. Chartbook: LS Crude Base.cht | 2015-02-23 14:18:47 Chart #1 is performing a full recalculation because it has been tagged. Chartbook: LS Crude Base.cht | 2015-02-23 14:18:47 Chart #5 has tagged chart #1 for full recalculation. Chartbook: LS Crude Base.cht | 2015-02-23 14:18:49 Chart #4 has tagged chart #1 for full recalculation. Chartbook: LS Crude Base.cht | 2015-02-23 14:18:49 Chart #1 is performing a full recalculation because it has been tagged. Chartbook: LS Crude Base.cht | 2015-02-23 14:18:49 Chart #5 has tagged chart #1 for full recalculation. Chartbook: LS Crude Base.cht | 2015-02-23 14:19:02 Chart #4 has tagged chart #1 for full recalculation. Chartbook: LS Crude Base.cht | 2015-02-23 14:19:02 Chart #1 is performing a full recalculation because it has been tagged. Chartbook: LS Crude Base.cht | 2015-02-23 14:19:02 Chart #6 has tagged chart #1 for full recalculation. Chartbook: LS Crude Base.cht | 2015-02-23 14:19:09 Chart #1 is performing a full recalculation because it has been tagged. Chartbook: LS Crude Base.cht | 2015-02-23 14:19:10 Chart #6 has tagged chart #1 for full recalculation. Chartbook: LS Crude Base.cht | 2015-02-23 14:19:12 Chart #1 is performing a full recalculation because it has been tagged. Chartbook: LS Crude Base.cht | 2015-02-23 14:19:13 Chart #6 has tagged chart #1 for full recalculation. Chartbook: LS Crude Base.cht | 2015-02-23 14:19:24 Chart #1 is performing a full recalculation because it has been tagged. Chartbook: LS Crude Base.cht | 2015-02-23 14:19:24 Chart #6 has tagged chart #1 for full recalculation. Chartbook: LS Crude Base.cht | 2015-02-23 14:19:45 Chart #1 is performing a full recalculation because it has been tagged. Chartbook: LS Crude Base.cht | 2015-02-23 14:19:45 Chart #6 has tagged chart #1 for full recalculation. Chartbook: LS Crude Base.cht | 2015-02-23 14:19:47 Chart #1 is performing a full recalculation because it has been tagged. Chartbook: LS Crude Base.cht | 2015-02-23 14:19:47 Chart #5 has tagged chart #1 for full recalculation. Chartbook: LS Crude Base.cht | 2015-02-23 14:19:49 Chart #4 has tagged chart #1 for full recalculation. Chartbook: LS Crude Base.cht | 2015-02-23 14:19:49 Chart #1 is performing a full recalculation because it has been tagged. Chartbook: LS Crude Base.cht | 2015-02-23 14:19:49 Chart #6 has tagged chart #1 for full recalculation. Chartbook: LS Crude Base.cht | 2015-02-23 14:19:51 Chart #1 is performing a full recalculation because it has been tagged. Chartbook: LS Crude Base.cht | 2015-02-23 14:19:51 Chart #5 has tagged chart #1 for full recalculation. Chartbook: LS Crude Base.cht | 2015-02-23 14:20:05 Chart #4 has tagged chart #1 for full recalculation. Chartbook: LS Crude Base.cht | 2015-02-23 14:20:05 Chart #1 is performing a full recalculation because it has been tagged. Chartbook: LS Crude Base.cht | 2015-02-23 14:20:06 Chart #6 has tagged chart #1 for full recalculation. Chartbook: LS Crude Base.cht | 2015-02-23 14:20:11 Chart #1 is performing a full recalculation because it has been tagged. Chartbook: LS Crude Base.cht | 2015-02-23 14:20:12 |
| [2015-02-23 19:29:43] |
| Richard Novak - Posts: 24 |
|
Something I should mention is that I'm using Renko bars in the longer timeframes that I'm referencing. I'm wondering if that has something to do with it. The Renko bars are sometimes painted and then hidden. It appears that the recalculations may occur when the bars are painted / hidden.
|
| [2015-02-23 20:10:18] |
| |
|
Are you using one of the Renko studies? There is something going on in chart 6, 5 and 4 causing a full recalculation of chart 1. It would be a full recalculation of those charts or a reload of the chart. Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service: Sierra Chart Teton Futures Order Routing |
| [2015-02-23 20:24:40] |
| Richard Novak - Posts: 24 |
|
There are two Renko studies available, Renko Study and Renko Study Enhanced. I'm using the Renko Study. I've been watching it and the recalculations definitely appear to be happening after a Renko bar is painted or hidden. Is the source code available for the Renko study that I could take a look at? |
| [2015-02-23 22:40:13] |
| Richard Novak - Posts: 24 |
|
Hello, I found the source code for the Renko study I'm using. I think the problem might be related to the resizing of the Renko bar data array. When you have new data updated within the same base bar, the program deletes all of the Renko array elements associated with the current base bar and then adds the elements for each brick again. My guess is that the resizing of the Renko array is triggering a recalculation. I don't see an explicit trigger of the recalculation, but I'm guessing that it may be done in the function call to sc.ResizeArrays. I suppose it could also be triggered when the new elements are added in the call to sc.AddElements. I did notice that there is a field in the sc structure called FlagFullRecalculation but it is not called from within the study. Maybe tomorrow I'll try setting that to zero after the resize and adding of elements to inhibit the full recalculation. My guess is that there is an event handler that is triggered in the background to deliver the recalculation events to each chart that references it, so that probably won't work. I'd really like to figure out how to disable these recalculations if possible. Any suggestions you may have would be greatly appreciated. Thanks, Richard |
| [2015-02-24 08:10:06] |
| |
|
The proper solution to this is not to use the Renko studies. Those are no longer supported. You need to use the Renko Bar Bar Period Type found in Chart >> Chart Settings. Refer to the Chart Settings documentation for more information. Your analysis in post #7 is not correct. The problem is when a Renko chart loses a bar that is apparently what is triggering the full recalculation in dependent charts. We have to check the code to verify it. There is nothing the study function is doing to actually trigger the recalculation. It is being detected in another place. Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service: Sierra Chart Teton Futures Order Routing Date Time Of Last Edit: 2015-02-24 08:13:29
|
| [2015-02-24 09:14:44] |
| Richard Novak - Posts: 24 |
|
Hello, I did some additional debugging this morning and found that the tagging for recalculation is occurring after the elements are added to the array. At at all possible I would like to try to find a work around / fix for this. I'm aware of the Renko bars that can be specified in the Chart Settings. Unfortunately those Renko bars do not meet my needs. The Renko bars generated from the study are different and better because of how they work. The study Renko bars are redrawn each time based on the underlying bar. This provides a much clearer picture of the market direction and eliminates noise from previous brick moves within the same bar. This provides an excellent method of establishing a reference timeframe that can be used to stay on the right side of the trend. The Renko study works exactly how I need it to work with the exception of the generation of recalculation events. In my particular case the recalculation events are not needed and add no value. I'm have a single chart containing a custom trading system study that reads the current values from the charts containing the Renko studies and uses that information to make trading decisions. Given this method the notification and recalculation are not necessary. I just need some method of disabling the tagging for recalculation from the Renko study. Thank you for your time and I hope we can find a resolution to this problem. |
| [2015-02-24 13:47:32] |
| Richard Novak - Posts: 24 |
|
Hello, I found a way to properly maintain the trend state with the full recalculations taking place. I modified the program to only assign values to the subgraph arrays if the current value is zero. Once the initial load is performed the values are initialized, the subgraph arrays are only updated for new bars. I also reduced the amount of data in the chart being tagged for recalculation to an absolute minimum. I normally trade 6 to 8 markets and I'm concerned about performance with having all of the recalculations being done. If you have any other thoughts about stopping the recalculations please let me know. I may try to rewrite the Renko study to try to resolve the recalculation issue. Thank you |
| [2015-02-24 18:35:29] |
| |
|
We need to do some testing today on this.
Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service: Sierra Chart Teton Futures Order Routing |
| [2015-02-25 05:47:43] |
| Richard Novak - Posts: 24 |
|
FYI. The problem with the auto recalculation was observed while using a base chart type of volume per bar with the Renko study applied. I have a few suggestions about the design of your software. 1. It would be helpful to have an option to disable auto recalculations. The software currently has menu functions for manually doing this if needed. 2. It would be helpful to have an option to specify whether data arrays are cleared when reloads / recalculations are done. Ideally this would be provided on an array by array basis. It appears anytime that a reload / recalculation is performed the data arrays are cleared. This is not desirable in some cases. In my systems I normally perform multiple timeframe analysis and quite often generate indicators in shorter timeframes that are based on longer timeframe charts. Whenever a reload or recalculation is done, the indicators values in the shorter timeframes are reevaluated and computed based on the current indicators in the longer timeframes. As a result, the shorter timeframe indicators values no longer reflect the value that was present when the shorter timeframe bar was generated. To get around this problem I normally maintain my own arrays that are not cleared when a reload / recalculation is done. When a reload / recalculation is done I copy the data values from my arrays to your data arrays which restores the captured values. This ensures that the charts are restored just as they looked in real-time. Thank you |
| [2015-02-25 22:08:30] |
| |
|
1. We do not know what this means, or not precisely, and no such option would be added anyway. 2. We cannot change this. Really there is no chance at all of a change like this. You are asking to change a basic fundamental design. And also there are different kinds of recalculations that can occur and the arrays do not always get cleared on every recalculation. You need to realize the consequences of us adding these kinds of things and complicating Sierra Chart by creating inconsistencies caused by options like this. We cannot be everything to everybody because then the program gets to be so complicated it makes it confusing and makes it incredibly difficult for us to support. Anyway, we checked on the basic issue you described of where a chart that is referencing another chart is tagged by that chart when using the Renko study. This does not occur when a Renko bar is added. We confirmed it only happens when a bar is removed but that can happen very quickly when a bar is immediately added after, and you may not visually notice it. At this time, we consider this thread closed and we cannot spend further time on this. Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service: Sierra Chart Teton Futures Order Routing Date Time Of Last Edit: 2015-02-26 08:38:22
|
To post a message in this thread, you need to log in with your Sierra Chart account: