Support Board
Date/Time: Wed, 07 May 2025 00:55:23 +0000
[Programming Help] - How does Sierra Charts discount the opening gap calculating Moving averages?
View Count: 207
| [2024-11-29 12:47:44] |
| User813832 - Posts: 12 |
|
Hi, I am trying to write some systems in python and I have written a market regime filters (based on moving averages) in python and ACSIL. However I notice that when exporting the RTH data, the moving averages in the python code respond strongly to big moves when the market gaps up and down (because I am only looking at prices from the RTH session, so for example there is a big jump between 16:15 and 09:30). However, when I look at Sierra Charts, I can see the moving average barely responds at all to the opening gap and stays extremely smooth. I prefer this approach. I have tried to brainstorm how this is done or how to recreate this, I tried to align the close of prior session with the open of new session, but it doesn't have the same affect. I can't for the life of me think how the opening gap is completely smoothed out. Is the moving average being calculated on ETH prices even though the chart is only displaying RTH? Currently, I have rewritten my python code to just take the moving average calculations done by SC rather than calculate them itself (as I don't know how to discount the opening gap). This approach works, but it means I need to completely revise my data every time I want to change some variables. I am not sure if this question is out of order or the way its done is some trade secret or something, if you want to keep it secret feel free to tell me that. But it sure would help me if you'd steer me in the right direction and I can align my python code with the way the MAs are calculated in reference to the opening gap in SC. As I say, it's really quite impressive how smooth the MAs stay when there is a gap up/down and I have no idea how they stay so smooth. Many thanks! As always love SC, keep up the great work. Date Time Of Last Edit: 2024-11-29 12:49:26
|
| [2024-11-29 16:44:18] |
| Sawtooth - Posts: 4212 |
|
However, when I look at Sierra Charts, I can see the moving average barely responds at all to the opening gap and stays extremely smooth.
I've not seen this. I only see the MA 'catching up'. It is looking back only at bars that exist on the chart.Here's an example of how to start an MA at the RTH Open, and ignore an opening gap: (But this is probably the opposite of what you want.) https://www.sawtoothtrade.com/free-stuff-18.html |
| [2024-11-29 17:00:34] |
| User431178 - Posts: 663 |
|
I've not seen this.
Me neither. On most (all?) of the reference pages for Moving Average studies you can find a link to download a spreadsheet showing the calculation method. For example, if you scroll to the bottom of this page - Moving Average - Exponential - you will see a link titled "Moving_Average_-_Exponential.27.scss". Once you have the relevant spreadsheet(s) you can check against your python moving average calculations to ensure consistency in method. |
| [2024-11-29 17:11:19] |
| Sawtooth - Posts: 4212 |
|
the reference pages for Moving Average studies you can find a link to download a spreadsheet showing the calculation method.
Or go here for three better known ones:Spreadsheet Example Formulas and Usage: Moving Averages Date Time Of Last Edit: 2024-11-29 17:15:53
|
| [2024-11-30 18:18:37] |
| Sawtooth - Posts: 4212 |
|
I have done the calculations using this raw data and the moving average on bar 1 shouldn't be 5743.08.
What do you think it should be?If you add the Spreadsheet Study study, and copy/paste column E for those 30 bars (include the first bar of the new RTH) to Excel, and do the math with this formula: =SUM(A1:A30)/30 ... you get 5743.083 See attached pic. |
SMA30.PNG| [2024-11-30 18:45:54] |
| User813832 - Posts: 12 |
|
Hi, thanks for all your help. Your surprise caused me to recheck all the averages again and I realised the problem was not with SC or with the average calculations - they were all correct and to be expected. The issue was that pandas was sorting the dates as strings, not as actual dates. So when using diff() because the dates were not sorted, sometimes it would find the difference between, for example, 15/09/24 and 16/10/24 because its just sorting chronologically. Now I've sorted by date it works fine. Thanks!
|
To post a message in this thread, you need to log in with your Sierra Chart account: