Login Page - Create Account

Support Board


Date/Time: Fri, 29 Mar 2024 12:32:25 +0000



ACSIL - Increase the number of sub-graphs

View Count: 1554

[2014-02-05 05:10:10]
ejtrader - Posts: 688
SC Team - Trying to consolidate few of the custom studies into a single study and running into limitation of number of sub-graphs available. Would it be possible to increase this from current 40 to 60 (or preferably 75)?

PS: Please note that I have optimized enough on this aspect and really in need of higher number of sub-graphs.

thanks
Date Time Of Last Edit: 2014-02-05 06:18:49
[2014-02-05 09:46:49]
Sierra Chart Engineering - Posts: 104368
Do you need these for drawing? Keep in mind that each Subgraph contains additional internal data arrays.
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
[2014-02-05 14:42:50]
ejtrader - Posts: 688
SC team - Yes, I do need this for drawing (though most of the time only few of them would be drawn - conditionally). I am already using internal data arrays ( sg.Array[] for intermediate calculations).

Thanks
[2014-02-05 17:19:39]
Sierra Chart Engineering - Posts: 104368
We do not see this change coming anytime soon. This is not simple to increase the number of arrays and we have a lot of other things to do. It is already very high. Please do not put reliance on an increase in the number of study Subgraphs.
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
[2014-02-05 17:22:21]
ejtrader - Posts: 688
If it is not simple to change - It's understandable. Would look for alternate ways to do this - probably with couple of studies rather than single study - which would have been more helpful. However - would you please keep this in your to-do list to get this done at some point rather than discarding it completely.

Edit - I would bring this up once in every few weeks - just as a reminder so that this is not forgotten completely. Hope you don't mind.

Thanks
Date Time Of Last Edit: 2014-02-06 17:35:05
[2014-02-06 15:16:19]
ejtrader - Posts: 688
SC Team - Wondering how many internal arrays are available.

sg.Array[0]
sg.Array[1]
..
sg.Array[N] - What's the Max N here?

Thanks
Date Time Of Last Edit: 2014-02-06 15:17:18
[2014-02-11 05:50:09]
ejtrader - Posts: 688
SC Team - Whenever you get to increasing the number of sub-graphs, would you please see the possibility of adding few persistent vars for floats in this form ?

sc.PersistVars->floats[N]

You currently have for integers & doubles but not floats in this specific form.

Thanks
Date Time Of Last Edit: 2014-02-11 05:51:05
[2014-02-11 05:50:59]
Sierra Chart Engineering - Posts: 104368
A double is better than a float because it has more precision. There are 64 doubles. Is that not enough?
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
[2014-02-11 05:55:11]
ejtrader - Posts: 688
Fair enough. Thought of storing the current price values in their original form rather than converting them to doubles. the current number of 64 floats is good enough. But the floats[N] etc would allow me to use dynamic variable name to define them to avoid any kind of potential conflicts with the reuse and at the same time keeping the code clean. This is not so critical feature request though. Just thought of asking in case if you are ever going to visit this area for any changes in the near future.

Thanks


// Integers - convenient to use in this form
int ivars=0;
int& i1=sc.PersistVars->Integers[ivars++];
int& i2=sc.PersistVars->Integers[ivars++];
..

// Floats - no such option
int fvars=0;
float& f1=sc.PersistVars->floats[fvars++];
float& f2=sc.PersistVars->floats[fvars++];
..


Date Time Of Last Edit: 2014-02-11 06:06:02

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

Login

Login Page - Create Account