Too Complex - Any thoughts overcoming processing limitations?

[perseverance_trading1]

Some background here, I've spent about sixteen hours writing logic for a watchlist for what I describe as the full lifecycle of price movement made of eleven phases.

For example: A setup goes from bullish, to bullish pullback, to bearish, to bearish pullback.

The definition for each phase (II Pullback for example) is made up of conditional groupings which include what I describe as the makeup for that distinct sub-phase (such as Pullback type1, pullback type2, pullback type 3).

Each subphase: (II. Pullback Type 1) is made up of conditional operation checks which define that subphase:
Pullback Type1: (A>B) and (C>F) and (R>S) and (S<L) and (Q>1) and (W>3);
Pullback Type2: ....
Pullback Type3: ....
Pullback Type4: ....
.....

The operational checks (for each subphase) are from six to ten definitions long. For example: pullback type1 above is six operation checks long.

When inputting about 65% of the logic, I received this error:
"com.devexperts.tos.thinkscript.runtime.TooComplexException: The complexity of the expression suggests that it may not be reliable with real-time data."

The issue appears that as I add the remaining four phases, I have reached a limitation. I have considered separating the bullish from the bearish phases. This will make two logic instances of half the size.

I am not a programmer, but worked as a business analyst, so I am familiar with technical concepts. However, I am not familiar with optimization techniques.

My question is: What can I do to optimize the code to be able to accommodate the remaining 40% of the logic in one definition set?

Any thoughts overcoming the conditional limits placed on TOS processing?

 

[Fluideng]

I've seen this type of question before. I think because of the limitations. You could make it an indicator and use a flex grid. Less stocks on a flex grid but it might be a work around.

 

[perseverance_trading1]

I've seen this type of question before. I think because of the limitations. You could make it an indicator and use a flex grid. Less stocks on a flex grid but it might be a work around.

Thank you @Fluideng . Believe it, or not, I've taken the codeset and asked ChatGPT to combine like functions and remove any redundancy. It's taken a few iterations but some recommendations have been made. I think I might split the lifecycle into bullish and bearish parts but will do that as a last resort. If you think of anything else let me know. Thank you!

 

[MerryDay]

Some background here, I've spent about sixteen hours writing logic for a watchlist for what I describe as the full lifecycle of price movement made of eleven phases.

For example: A setup goes from bullish, to bullish pullback, to bearish, to bearish pullback.

The definition for each phase (II Pullback for example) is made up of conditional groupings which include what I describe as the makeup for that distinct sub-phase (such as Pullback type1, pullback type2, pullback type 3).

Each subphase: (II. Pullback Type 1) is made up of conditional operation checks which define that subphase:
Pullback Type1: (A>B) and (C>F) and (R>S) and (S<L) and (Q>1) and (W>3);
Pullback Type2: ....
Pullback Type3: ....
Pullback Type4: ....
.....

The operational checks (for each subphase) are from six to ten definitions long. For example: pullback type1 above is six operation checks long.

When inputting about 65% of the logic, I received this error:
"com.devexperts.tos.thinkscript.runtime.TooComplexException: The complexity of the expression suggests that it may not be reliable with real-time data."

The issue appears that as I add the remaining four phases, I have reached a limitation. I have considered separating the bullish from the bearish phases. This will make two logic instances of half the size.

I am not a programmer, but worked as a business analyst, so I am familiar with technical concepts. However, I am not familiar with optimization techniques.

My question is: What can I do to optimize the code to be able to accommodate the remaining 40% of the logic in one definition set?

Any thoughts overcoming the conditional limits placed on TOS processing?

The ToS platform condition wizard which is utilized as part of the scanner, watchlists, and conditional orders is designed purposely to only handle limited logic in order to conserve TDA resources.

Members have found limited workarounds:
https://usethinkscript.com/threads/answers-to-commonly-asked-questions.6006/#post-57834

 

[halcyonguy]

Some background here, I've spent about sixteen hours writing logic for a watchlist for what I describe as the full lifecycle of price movement made of eleven phases.

For example: A setup goes from bullish, to bullish pullback, to bearish, to bearish pullback.

The definition for each phase (II Pullback for example) is made up of conditional groupings which include what I describe as the makeup for that distinct sub-phase (such as Pullback type1, pullback type2, pullback type 3).

Each subphase: (II. Pullback Type 1) is made up of conditional operation checks which define that subphase:
Pullback Type1: (A>B) and (C>F) and (R>S) and (S<L) and (Q>1) and (W>3);
Pullback Type2: ....
Pullback Type3: ....
Pullback Type4: ....
.....

The operational checks (for each subphase) are from six to ten definitions long. For example: pullback type1 above is six operation checks long.

When inputting about 65% of the logic, I received this error:
"com.devexperts.tos.thinkscript.runtime.TooComplexException: The complexity of the expression suggests that it may not be reliable with real-time data."

The issue appears that as I add the remaining four phases, I have reached a limitation. I have considered separating the bullish from the bearish phases. This will make two logic instances of half the size.

I am not a programmer, but worked as a business analyst, so I am familiar with technical concepts. However, I am not familiar with optimization techniques.

My question is: What can I do to optimize the code to be able to accommodate the remaining 40% of the logic in one definition set?

Any thoughts overcoming the conditional limits placed on TOS processing?

we can't help fix code when no code is posted.

i would start with making a lower chart study. try to get all the logic working. make a study that displays a row of points for each input and a row of points for each of the 11 outputs. change the color of the point, wether its true or false.
you might find some conditions are the same or close enough , as others and can be removed.
an example
https://usethinkscript.com/threads/donchian-trend-ribbon-for-thinkorswim.10861/#post-95354


try to unload extra studies. every loaded study is pulling data.
how many studies do you have loaded, in columns and on charts? write down a list and save workspaces, then unload them.

reduce calls for external data. instead of using close a dozen times, use it once,
def cls = close;
then reference cls in formulas.

 

[perseverance_trading1]

The ToS platform condition wizard which is utilized as part of the scanner, watchlists, and conditional orders is designed purposely to only handle limited logic in order to conserve TDA resources.

Members have found limited workarounds:
https://usethinkscript.com/threads/answers-to-commonly-asked-questions.6006/#post-57834

Thank you @MerryDay

 

[perseverance_trading1]

we can't help fix code when no code is posted.

i would start with making a lower chart study. try to get all the logic working. make a study that displays a row of points for each input and a row of points for each of the 11 outputs. change the color of the point, wether its true or false.
you might find some conditions are the same or close enough , as others and can be removed.
an example
https://usethinkscript.com/threads/donchian-trend-ribbon-for-thinkorswim.10861/#post-95354


try to unload extra studies. every loaded study is pulling data.
how many studies do you have loaded, in columns and on charts? write down a list and save workspaces, then unload them.

reduce calls for external data. instead of using close a dozen times, use it once,
def cls = close;
then reference cls in formulas.

Thank you @halcyonguy . I am going to implement the recommendation you made and see where that goes. Will update accordingly including the code as well. I think the issue is specific to defining so much of the lifecycle that I might need to consolidate what a bullish pullback means from ten scenarios to two, taking the essence of what a pullback is, rather than all ten scenarios I have logic for and doing the same across all scenarios.