Login Page - Create Account

Support Board


Date/Time: Fri, 29 Mar 2024 15:17:34 +0000



[User Discussion] - GetStudyPeakValleyLine doesn't work correctly with Volume by Price studies

View Count: 1046

[2018-11-18 21:17:51]
Usermb - Posts: 126
GetStudyPeakValleyLine() doesn't seem to be working correctly for Volume by Price studies: the value returned in PeakValleyType is always 0 (PEAKVALLEYTYPE_NONE), even when the value of PeakValleyLinePrice and StartIndex is set correctly.
Furthermore the value returned by GetStudyPeakValleyLine() is correct and as expected not zero for PeakValleyIndex between 0 and up to (but excluding) the number of levels in the profile.

The behaviour is the same for "Multiple Profiles" period type or for a single one.

Given a "Multiple Profiles" period type, ProfileIndex seems to be inconsistent across functions:
- GetNumPriceLevelsForStudyProfile must have ProfileIndex set to 1 to reference the prior profile (second from right to left). 0 refences the most recent profile (most to the right)
- GetStudyPeakValleyLine must have ProfileIndex set to -1 to reference the most recent profile. ProfileIndex=0 refers to the first profile in the chart (the one starting at bar index 0), ProfileIndex=1 references the one next towards right after the one with ProfileIndex=0 and so on. Setting ProfileIndex to lower than zero seems to always reference the most recent profile (most to the right). It doesn't appear to be possible to reference the prior profile.

I didn't test it with TPO profiles.
[2018-11-19 01:31:56]
Sierra Chart Engineering - Posts: 104368
The problem with sc.GetStudyPeakValleyLine will be resolved in the next release. And the documentation has now been updated related to the ProfileIndex parameter.

We cannot change the behavior of the ProfileIndex parameter in the sc.GetNumPriceLevelsForStudyProfile function without creating compatibility problems with existing 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: 2018-11-19 01:35:21
[2018-11-20 23:40:19]
Usermb - Posts: 126
The issues from the original post appear to have been fixed in 1845. Thank you.

Now that I am able to really test it out, PeakValleyExtensionChartColumnEndIndex doesn't seem to be set to the correct bar array index.
Given a multiple profiles Volume by Price study with a profile for every session, with Peaks and Valleys configured to extend till the end of the session, PeakValleyExtensionChartColumnEndIndex is still always set to zero.

StartIndex is set correctly.
[2018-12-08 22:48:42]
Usermb - Posts: 126
Could you please provide an update regarding the PeakValleyExtensionChartColumnEndIndex bug as described on post #3?
For the VolumeByPrice studies I tested with, EndIndex is always set to zero.

I also tested it with a TPO study, EndIndex is set to the wrong value whereby the StartIndex is correct. Here's an example of what I mean by wrong: given a TPO study with multiple profiles, a profile every 12 bars, StartIndex is set as expected to (0, 12, 24...) and EndIndex is set to (167, 167, 38...)

Thank you.
[2018-12-08 22:59:08]
Sierra Chart Engineering - Posts: 104368
Given a multiple profiles Volume by Price study with a profile for every session, with Peaks and Valleys configured to extend till the end of the session, PeakValleyExtensionChartColumnEndIndex is still always set to zero.
This does make sense. It would be 0 in this case.

given a TPO study with multiple profiles, a profile every 12 bars,
We have to stop you here. TPO profiles do not correspond to bars. There can be no doubt that PeakValleyExtensionChartColumnEndIndex is correct. It is simply impossible for it to be "wrong". It is not useful in the case of TPO charts. Likely its value will not make sense to you but it internally is correct. There can be no doubt of this whatsoever. Case closed.
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: 2018-12-08 23:00:52
[2018-12-09 00:07:04]
Usermb - Posts: 126

This does make sense. It would be 0 in this case.
To be honest, I was not able to find a single case, where it is not zero. I iterate over all profiles on the chart, hundreds of different ProfileIndex values.
StartIndex is always correct, EndIndex is always zero.
Could you please let us know, when EndIdex is being set? I would really love to understand how it can be used.
UPDATE: according to the updated documentation, this is always set to zero when "extend until future intersection" for Peaks and Valleys is not used.

To claim that there are no bars for a give TPO profile instance (ProfileIndex) can potentially be misleading and not what is observed or what this function is returning. The number of bars a TPO profile appears to span across is In:2 divided by In:5 of the given TPO. Since StartIndex is set correctly, it is imho a good enough indication that it is able to deal with bars fine. I need the StartIndex to compute when a profile starts (point in time).

You know, if you don't have time to look into this kind of stuff, I do understand and I accept that the case is closed just fine, I already have work arounds for everything, but please update the documentation to reflect the reality.
UPDATE: thank you for updating the documentation, the old version I looked at is attached as proof that I didn't waste your time.

UPDATE2: TPO mystery solved. GetStudyPeakValleyLine returns EndIndex set to the start bar index of the TPO profile that the extended valley/peak would first intersect, even when the TPO is set to extend the Valleys and Peaks only to the end of the period. Thus EndIndex is pseudo-correct for TPO. To be 100% correct as per your documentation, you'd have to return zero when the Peaks and Valleys for the TPO profile are set to extend to the end of the period (and maybe window too?).
You updating the documentation made it possible to figure this out. So thanks again for that.
Date Time Of Last Edit: 2018-12-09 00:22:13
imageCapture3.PNG / V - Attached On 2018-12-09 00:03:22 UTC - Size: 35.24 KB - 333 views

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

Login

Login Page - Create Account