Support Board
Support Board
Search Board
Control Panel
View My Posts / Threads
Direct MessagesDate/Time: Sat, 18 May 2024 06:22:14 +0000
Inconsistent data from VolumeByPrice study when back-testing
View Count: 541
| [2021-04-21 07:54:19] |
| Ernie Doo - Posts: 46 |
|
I get very inconsistent data from the VbP study using sc.GetVolumeAtPriceDataForStudyProfile and sc.GetNumPriceLevelsForStudyProfile when back-testing. The VbP study is the first one I load with StudyID 1 and the study I developed has StudyID 2. Those are the only 2 studies I have loaded in my chart. Inside my code I added "sc.CalculationPrecedence = LOW_PREC_LEVEL;" to ensure VbP is calculated first. Now, when I back-test at speed 1 everything is consistent and I get same results at the same times. The problem comes when I start increasing the Replay speed. But even as low as a speed of 120 the data starts getting inconsistent. I start getting different volumes. When I increase the replay speed above 120 so does the inconsistency. If I dare to go to the max replay speed all hell brakes lose; I get big volume differences and I even start getting huge different values for Price Levels (sc.GetNumPriceLevelsForStudyProfile) at a same given time (eg. I could be getting a Price Level of 100 and the next run I would get 30 at the same time/bar). The replay mode I use is "Accurate Trading System Back TestMode" which was recommended by you guys in other posts. How can I get more consistency when back-testing at high speeds? The VbP profile is of great value to my trading but not if I have to back-test at very low speeds. I don't even need it to be that accurate, I just need a lot of consistency/repeatability. If somehow I could have a snapshot of last bar's VolumeByPrice, or something like that, I could make some decisions. I am certain my computer's cpu is not overloaded. When back-testing my cpu load is always around 10%. I am running an Intel 6 core i7-8700 @3.2Ghz with 32 GB RAM. Besides, I have tested so many functions developed by you guys (TPO Profiles, Moving Averages, Bollinger, True Range, etc...) and everything has been running flawlessly at max speeds, until now. Thanks, Ernesto |
| [2021-04-21 21:02:07] |
| |
|
When you look at the chart during the replay, do you notice any issues with the Volume Profiles displayed? You should not. These functions will work 100% accurately and consistently under all conditions: sc.GetVolumeAtPriceDataForStudyProfile and sc.GetNumPriceLevelsForStudyProfile
They simply will access the data from a volume profile, as it exists at that moment in time. There simply is no other possibility. We have no idea what your code is doing and how you are coming to this conclusion. We do not specifically understand this: data starts getting inconsistent. I start getting different volumes.
It is impossible really for us to comment on this at all. It really requires a detailed level of debugging which we cannot get involved with. 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: 2021-04-21 21:02:56
|
| [2021-04-22 02:58:07] |
| |
|
One thing that has come to mind, is that there certainly will be inconsistencies with the creation of Volume Profiles based upon the visible bars with varying back tests speeds.
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: 2021-04-22 02:58:17
|
| [2021-04-22 09:23:42] |
| Ernie Doo - Posts: 46 |
|
I think my problem comes exactly from what you mentioned last. I think you are spot on!! One thing that has come to mind, is that there certainly will be inconsistencies with the creation of Volume Profiles based upon the visible bars with varying back tests speeds.
After a lot of testing and debugging I believe I have narrowed it down. I think that during replay at high speeds the Volume By Price study does not finish "Drawing or plotting" the profile at the moment I call sc.GetVolumeAtPriceDataForStudyProfile and sc.GetNumPriceLevelsForStudyProfile. This is of course an assumption because I do not know internally how the VolumeByPrice study exactly works. I now found out that the Volume does not vary (as I said before and as I explain below) and is actually very accurate. However, the Price Levels value varies very strongly. For example, I tested on S&P, in a Minute Chart, exactly at 2021/01/07 16:43 when that bar opened and in one test I had 161 price levels but in the next test only 73. Just do a quick test. It does not require a lot of debugging at all. Test twice at high speeds and/or max speed. Read out the Price Levels at any time you choose. You will get big different values almost every time (more than 90% of the time if not more). Please, just have a look and tell me what you think. Just to clear things up I am answering your queries here below: We have no idea what your code is doing and how you are coming to this conclusion.
I wrote a simple code just to test this. Every time sc.UpdateStartIndex changes (ie. every new bar) I check 10 ticks up and 10 ticks down from this new bar's OPEN and search for the lowest volumes and save them with their matching prices. To do this I search through sc.GetVolumeAtPriceDataForStudyProfile using the value I get from sc.GetNumPriceLevelsForStudyProfile as limit until I find this bar's OPEN (sc.BaseData[SC_OPEN][sc.UpdateStartIndex]). Once I found it I just check 10 ticks up and down. I then print these values out into a file. So, I can debug or just look at my file after the test. You are completely right about this. We do not specifically understand this:
data starts getting inconsistent. I start getting different volumes. I made a mistake. The Volumes don't vary, they are actually very accurate and consistent. Since I am saving the lowest volumes with their corresponding prices sometimes the lowest volume I was saving corresponded, of course, to a different price. This was caused because the Price Levels were different from last test even though I was analyzing the same bar. |
| [2021-04-23 02:57:43] |
| Ernie Doo - Posts: 46 |
|
Hello SC team. Any comments before we go into the weekend would be greatly appreciated. Thanks
|
| [2021-04-23 06:54:19] |
| |
|
Do you have this Input setting: Volume By Price Study: Volume Graph Period Type Set to Visible Bars? If you do, that would explain the problem. And that has no solution. If you do not, then we do not know the cause. Assuming you are not using visible bars, one solution is just to only analyze the data for a chart bar, when it is closed by using this function: sc.GetBarHasClosedStatus() This will definitely solve the consistency issue but why there is an inconsistency to begin with, we do not know. 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: 2021-04-25 15:06:28
|
To post a message in this thread, you need to log in with your Sierra Chart account: