Support Board
Date/Time: Thu, 28 Nov 2024 05:40:34 +0000
Number bars calculate values 2 confusion
View Count: 832
| [2022-04-08 07:45:26] |
| User19165 - Posts: 346 |
|
Several subgraphs are not explained on your website. What is: - dominant ask bid % - average ask or bid volume per price In the screenshot on the last bar you can see there are no zero volumes, why does average non-zero ask volume differ from average ask volume per price? ask volume bid volume difference % states: "Ask Volume Bid Volume Difference Per Tick: This displays the difference between the total Ask Volume and the total Bid Volume divided by the range of the data in the bar per tick." Taking the last bar as an example. When I calculate the delta and divide it by the number of ticks in that bar, I do not get the value shown in your calculation. As an aside, you could make this easier for us traders to understand by just calling this the "delta". That is what every trader world wide knows it as. |
Private File |
| [2022-04-08 14:51:11] |
| John - SC Support - Posts: 36350 |
|
The "Dominant Ask Bid Percentage" is already in the documentation. We have added the missing entries for "Average Ask Volume Per Price" and "Average Bid Volume per Price". why does average non-zero ask volume differ from average ask volume per price
The "Average Non-Zero Ask Volume" gives the total Ask Volume divided by the number of Ask Volume levels (prices) that make up the total. Any 0 Ask volume levels are not included in this (i.e. they are not counted towards the divisor). The "Average Ask Volume Per Price" takes the total Ask Volume in the bar and divides it by the number of prices that make up the range less 1. If preferred, this can be thought of as the number of ticks that make up the range. Therefore these will give different answers if there are no zero values present as they divisor in each case will be different. ----- In answer to your next question of why it is this way - this was what was asked for by the customers that requested these. For the most reliable, advanced, and zero cost futures order routing, use the Teton service: Sierra Chart Teton Futures Order Routing |
| [2022-04-09 00:27:00] |
| User19165 - Posts: 346 |
|
So to clarify please. From your documentation: "Dominant Ask Bid Percentage: These numbers are displayed as a Percentage value with two decimal places and a % sign (for example: 82.37%) when the Input for Use Default Number Formatting for All Subgraphs is set to No, otherwise these numbers will follow the formatting defined in the Value Format setting for the study." That isn't really explaining to me what the calculation is...My hunch was that it would total up the ask volume and total up the bid volume for that bar and show it as a % based on the delta side. But when I manually calculated that for a bar it did not seem to match up to your values shown. The "Average Non-Zero Ask Volume" gives the total Ask Volume divided by the number of Ask Volume levels (prices) that make up the total. Any 0 Ask volume levels are not included in this (i.e. they are not counted towards the divisor).
The "Average Ask Volume Per Price" takes the total Ask Volume in the bar and divides it by the number of prices that make up the range less 1. If preferred, this can be thought of as the number of ticks that make up the range. So if we use the last bar on the screenshot as an example. Every price in that bar has volume on the ask, that is 6 prices. No zeros are present. Total up the ask volume = 78.6. This matches the average non-zero ask volume as you describe above great. Why does your average ask volume per price minus 1? It should not be thought as the number of ticks that make up the range. By your calculation above you will use a divisor of 5 rather than the 6 it should be. That is completely in error, in this particular bar shown. You are incorrectly assuming there is a zero ask volume on the lows of a bar. |
| [2022-04-11 14:50:47] |
| John - SC Support - Posts: 36350 |
|
In terms of the documentation, you are looking at the wrong spot. What you quote is the information on the special number format. The documentation for the subgraphs starts here: Numbers Bars: Numbers Bars Calculated Values Subgraph Descriptions By your calculation above you will use a divisor of 5 rather than the 6 it should be. That is completely in error, in this particular bar shown. You are incorrectly assuming there is a zero ask volume on the lows of a bar.
It is not "incorrect" it is just one of many ways to do the calculation. In this particular case, I was the engineer that did the work and the customers that wanted this information wanted the number of price levels minus 1. Therefore, we implemented what was asked for. If it is not what you need, then do not use it, and you can ask for a different item to be done that has what you want (although we can not say when we will be able to get to it). Or you can always use the Spreadsheet Formula to create the calculation you want and display that information. And, you could even create a custom study that uses the Numeric Information Table, which gives you the same functionality as the Numbers Bars Calculated Values grid. For the most reliable, advanced, and zero cost futures order routing, use the Teton service: Sierra Chart Teton Futures Order Routing |
| [2023-05-21 00:18:05] |
| j4ytr4der_ - Posts: 938 |
|
I just came upon this thread as I was trying to make sense of the "difference per tick" calculation, that keeps coming out wrong by my math. I believe this thread has explained why. The documentation states: Ask Volume Bid Volume Difference Per Tick: This displays the difference between the total Ask Volume and the total Bid Volume divided by the range of the data in the bar per tick.
For example, if the Total Ask Volume is 1000 and the Total Bid Volume is 1500 and the data spans prices from 2600.50 to 2602.00 with a Tick Size of 0.25, then the displayed value would be -83.33 ((1000 - 1500) / ((2602.00 - 2600.5) / 0.25). But from this thread, it appears that the result is actually divided by the number of ticks in the bar *minus 1*, rather than the number of ticks in the bar, as indicated in the documentation. Adding the minus 1 to my calculation has produced the same result the software is producing. As with the OP here I can't imagine why anyone wanted it to be minus 1, but that's their prerogative obviously. I do think the documentation could use updating to reflect this however. Also a small mathematical expression error: ((1000 - 1500) / ((2602.00 - 2600.5) / 0.25) should be ((1000 - 1500) / ((2602.00 - 2600.5) / 0.25)) Note the extra parenthesis at the end, since you were essentially mentioning a math expression as a parenthetical. A small thing sure, but in a formula those parenthesis are critical to get correct. |
| [2023-05-22 14:43:34] |
| John - SC Support - Posts: 36350 |
|
We have fixed the Parentheses error. Thank you.
For the most reliable, advanced, and zero cost futures order routing, use the Teton service: Sierra Chart Teton Futures Order Routing |
To post a message in this thread, you need to log in with your Sierra Chart account: