Home >> Support Board

Support Board

Date/Time: Mon, 29 Apr 2024 11:34:29 +0000

How to Post a Message for Support

ZigZag Volume / Length in Ticks missing fabs

View Count: 901

[2020-04-29 15:53:36] #1 [Go To First Post]
Yoda - Posts: 106
The Volume / Length in Ticks ("V/L") number (ln 36 in the ZigZag study) is reversing the sign on down moves. This happens when you set Volume to Accumulate (Ln 1) to Ask Bid Volume Difference For example, on UP moves: - If the volume to accumulate is positive, the V/L is also positive. - Likewise, if the volume to accumulate is negative, the V/L is also negative. However, on DOWN moves: - if the volume to accumulate is positive, the V/L is negative (it should be positive). - Likewise, if the volume to accumulate is negative, the V/L is positive (it should be negative). Looking at the code, it appears line 1199 in Studies 7.cpp should be taking the absolute of the ZigZagLineLength. I suggest the code should be: int64_t VolumeDividedByLengthInTicks = int64_t(AccumulatedVolume[ZigZagIndex] / fabs(ZigzagLineLength / sc.TickSize)); Date Time Of Last Edit: 2020-04-30 13:13:05

[2020-04-29 22:34:56] #2 [Go To First Post]
Sierra Chart Engineering - Posts: 104368
We did not have time to concentrate on this but we will apply this change to the next release. 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

[2020-04-30 00:00:40] #3 [Go To First Post]
User745789 - Posts: 173
However, on DOWN moves: - Likewise, if the volume to accumulate is negative, the length in ticks is positive (it should be negative). I am not seeing this. I am seeing -ve LiT for down moves when volume to accumulate is -ve However, on DOWN moves: - if the volume to accumulate is positive, the length in ticks is negative (it should be positive). Underlined: Why? LiT should always be -ve for a down move. Always.

[2020-04-30 00:24:59] #4 [Go To First Post]
User745789 - Posts: 173
The Length in Ticks number (ln 36 in the ZigZag study) is reversing the sign on down moves. Hang on, this is NOT talking about Length in Tick ( that is Line 27) Yoda is talking about Volume / Length in Ticks (Line 36) And it is working exactly as it should. Please do not change it.

[2020-04-30 01:10:55] #5 [Go To First Post]
Yoda - Posts: 106
we will apply this change to the next release. Thank you And it is working exactly as it should. Please do not change it. I see where the confusion is coming from. I should have noted that the issue only arises when you set Volume to Accumulate (Ln 1) to Ask Bid Volume Difference. If it is set to Total Volume, Bid Volume or Ask Volume, the Volume / Length in Ticks is always positive and is working correctly. However, with Ask bid Volume Difference, you have the discrepancies I noted in my first post. The suggested changed to the code does not affect Total Volume, Bid Volume or Ask Volume...it only corrects the situation when Volume to Accumulate is set to Ask Bid Volume Difference (which is both positive and negative). I hope that clears things up and you now see the need for the change.

[2020-04-30 03:53:13] #6 [Go To First Post]
User745789 - Posts: 173
Yoda-san, I am using Bid Ask Volume Difference for Ln 1 and I DO NOT see the issue you are reporting. It works perfectly for me. In your first post you said this: The Length in Ticks number (ln 36 in the ZigZag study) is reversing the sign on down moves. Length in Ticks is not Ln 36. You are looking at the wrong subgraph. Length in Ticks is Ln 27. Ln 36 is Volume Accumulated divided by Length in Ticks >>>>I think that is the source of the confusion here on your behalf, respectfully.<<<< Date Time Of Last Edit: 2020-04-30 04:37:49

[2020-04-30 12:41:37] #7 [Go To First Post]
Yoda - Posts: 106
Ln 36 is Volume Accumulated divided by Length in Ticks I have edited my first post to make it clear that I was speaking about Volume / Length in Ticks and the Bid Ask Volume Difference. This issue has now been resolved for me in version 2098.

[2020-04-30 13:08:58] #8 [Go To First Post]
User745789 - Posts: 173
You still refer to length in ticks 4 times in your first post. Is that what you intend? If so, it is very confusing. Sadly it sounds like the new version will ruin ln 36 for me. It was working perfectly. In a down move: Negative bid-offer difference volume divided by negative length in ticks should give a positive quotient for ln 36 Positive bid-offer difference volume divided by negative length in ticks should give a negative quotient for ln 36. That is exactly how it works now and should stay that way per logic and the rules of mathamatics.

[2020-04-30 13:34:10] #9 [Go To First Post]
Yoda - Posts: 106
I'm only referring to Volume / Length in Ticks. I've further edited my first post to make this clear. I understand what you are saying but I disagree with the logic. In my opinion, as I noted in my first post, if Ask Bid Volume Difference is negative the Volume / Length in Ticks should also be negative whether it's a down or up swing. Likewise if Ask Bid Volume Difference is positive, than the Volume / Length in Ticks should also be positive, whether it's a down or up swing. Prior to v 2098, the upswings worked this way, but the downswings were reversed. This was not consistent and didn't make sense.

[2020-05-01 02:28:18] #10 [Go To First Post]
User745789 - Posts: 173
I appreciate the post edits for clarity, thank you. It will take me all Saturday to work out how to make a custom study to preserve the mathematical integrity of the quotient. I know you understand my logic. But I still hold, that mathematically, if a term in a division is naturally negative, be that accumulated volume (V) or length in ticks (L), then the quotient has to be negative. This is what the brain expects. Also, by maintaining the natural market sign of the accumulated bid ask volume difference (aka "delta"), the user is instantly visually alerted to all instances where "delta" has diverged from price movement. Example, from attached image: V = Positive "delta" on a down move +126 (an anomaly) L = Negative length in ticks -7 V/L = 126/-7 = -18 This works consistently for both up moves and down moves alike: anytime there is a negative value for V/L, the user knows that the "delta" was divergent from price. It is a key feature of the quotient as currently calculated. Negative V/L is a consistent alert of delta anomaly, regardless of price direction move. And this can only happen if Accumulated Bid-Ask Difference is allowed to maintain its natural market sign in the division. :)


pic.png / V - Attached On 2020-05-01 02:07:44 UTC - Size: 1.96 KB - 236 views

[2020-05-01 12:05:49] #11 [Go To First Post]
Yoda - Posts: 106
It appears that we will not be able to agree on this point. Hopefully we can agree to disagree :) I believe the only change that they did was to add a fabs to line 1199 in Studies7.cpp . Therefore, if you want to have the same calculations as before, I would suggest you try deleting the fabs in line 1199 in Studies7.cpp and compile the zigzag study. In other words try changing: int64_t VolumeDividedByLengthInTicks = int64_t(AccumulatedVolume[ZigZagIndex] / fabs(ZigzagLineLength / sc.TickSize)); to... int64_t VolumeDividedByLengthInTicks = int64_t(AccumulatedVolume[ZigZagIndex] / (ZigzagLineLength / sc.TickSize));

[2020-05-02 23:27:46] #12 [Go To First Post]
User745789 - Posts: 173
Thanks :) Seeing as we are looking at this code, got any hints on how to declare VolumeDividedByLengthInTicks as Float or Double? I need a Real Number with 2 decimal places, rather than Integer? For instances with high tick length per move, but very low delta volume. I think I need to change int64_t to something else, but can't find it online. I had never even seen int64_t until today. I read here that Float should be avoided for financial coding, rounding errors? https://www.learncpp.com/cpp-tutorial/floating-point-numbers/ Is it as simple as double VolumeDividedByLengthInTicks = I note this doesn't mention "64". And 64 is a SC topic these days. Date Time Of Last Edit: 2020-05-02 23:29:04

[2020-05-04 03:22:01] #13 [Go To First Post]
User745789 - Posts: 173
For anyone else wanting to preserve the code from versions prior to 2098: the Zig Zag Study code starts on line 1262 of Studies7.cpp. But you also need to include the separate code for the variable "AccumulateZigZagVolume" starting on 956. So effectively, the ZigZag study code starts on line 956, and ends around 1865. Took me a while to discover that.

[2020-05-05 19:25:23] #14 [Go To First Post]
Sierra Chart Engineering - Posts: 104368
We will just revert back the change and the user in the original post, can make the appropriate change with their own version of the study.: How to Build an Advanced Custom Study from Source Code 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: 2020-05-06 08:21:26

To post a message in this thread, you need to log in with your Sierra Chart account: