I have just discovered that a study I have is doing the MC hidden recalculate (maybe only during replay mode but I am not sure yet). I know this because I am using fileappend on the first bar of the chart statement (recalculate wipes out a print statement log and thus you can not use the print statement to track the hidden recalculate). My binary search statement no longer triggers this hidden recaclulate so it is something else.
The request is for MC to have some sort of an optional popup alert to let us know it is doing this recalculate. Also ideally to have a log or something to somehow help use figure out what is doing it (where it is occuring). Maybe this log could at least include the bar that it is occuring on and the time it occured. It would be a large time saver.
In the mean time I have decided to have the first bar on the chart code set a GV that notifies me of the hidden recalculate. I suppose users who are only programming in MC's EL could have another study pick up the GV signal to both alert of it and log it.
Thanks much,
John.
Hidden recalculate log or optional popups request
- TJ
- Posts: 7752
- Joined: 29 Aug 2006
- Location: Global Citizen
- Has thanked: 1034 times
- Been thanked: 2228 times
- Bruce DeVault
- Posts: 438
- Joined: 19 Jan 2010
- Location: Washington DC
- Been thanked: 2 times
- Contact:
TJ is right, sometimes setting max bars back to a specific number that is known to be large enough can resolve this type of thing - MC/TS will evaluate analysis techniques with successively longer data series to determine the number of bars required, if set to auto. Signals don't work that way (for reasons that are probably obvious, and include live broker connectivity) - they require you to set it to a specific number.
Among the other circumstances that could cause a recalculation would include adding/changing a data series on the chart, or a reconnect cycle.
Among the other circumstances that could cause a recalculation would include adding/changing a data series on the chart, or a reconnect cycle.
Thanks guys, you are correct. I am going to pick a fairly high number, try it and get back to you. It makes sense actually because the statement tripping it is time_s[variable] but the variable is getting its value from a GV from another study. It is just recently I put that statement in so before there was no problem.
John.
John.
Last edited by bowlesj3 on 19 Apr 2010, edited 1 time in total.
- Bruce DeVault
- Posts: 438
- Joined: 19 Jan 2010
- Location: Washington DC
- Been thanked: 2 times
- Contact:
That did it guys. Thanks.
Seeing as this could happen in any study during any similar such changes I have it on my todo list now to drop some code in the currentbar = 1 code to notify me of any hidden recalculates (as mentioned above). However it will suggest checking the "auto detect" or "current hard coded setting". Also it will include log writes showing the maxbarsback values with each restart of the study. It is real easy to do and protects one against a nasty surprise during production runs due to something simply forgotten or not thought of.
Seeing as this could happen in any study during any similar such changes I have it on my todo list now to drop some code in the currentbar = 1 code to notify me of any hidden recalculates (as mentioned above). However it will suggest checking the "auto detect" or "current hard coded setting". Also it will include log writes showing the maxbarsback values with each restart of the study. It is real easy to do and protects one against a nasty surprise during production runs due to something simply forgotten or not thought of.
- Bruce DeVault
- Posts: 438
- Joined: 19 Jan 2010
- Location: Washington DC
- Been thanked: 2 times
- Contact:
Another idea that sometimes helps, if you want to make absolutely sure you don't have recalculations due to auto bars back determination in some EasyLanguage that essentially exists to perform a "side effect" such as outputting a text file or sending a live trade to a broker via a DLL, is to simply structure it deliberately as a signal rather than as an analysis technique (assuming you don't require plots as essential for what you are doing in the side effect) - in this way, because signals do not have auto lookback determination, you can be sure that will not happen. And, if you do require plots, you can often get that done via ELC to send the data over to a companion analysis technique.
Interesting Idea. For me (being discretionary) I use no signals at all so it would be better to create a function and drop it in every study at currentbar = 1.
One thing. I have noticed that the alert command does not seem to work until lastbaronchart. I have never dug into this to investigate farther. Am I correct on this?
One thing. I have noticed that the alert command does not seem to work until lastbaronchart. I have never dug into this to investigate farther. Am I correct on this?
- Bruce DeVault
- Posts: 438
- Joined: 19 Jan 2010
- Location: Washington DC
- Been thanked: 2 times
- Contact:
So I guess the function which runs at the currentbar=1 location will have to set a GV which is picked up by either another study at the lastbaronchart location or another program to give a popup notice. It could submit the study name as the GV value. Maybe even use a second GV containing the new maxbarsback setting.
Last edited by bowlesj3 on 19 Apr 2010, edited 1 time in total.
- Bruce DeVault
- Posts: 438
- Joined: 19 Jan 2010
- Location: Washington DC
- Been thanked: 2 times
- Contact:
I did this type of thing once before actually about 2/3 years ago. There was a counter of the number of currentbar=1 runs and if > 1 then it notified me. I should have set this up back then. It has to be initialized at the start of the trading day since the studies are only suppose to run currentbar=1 at the beginning of the day. If I force a recaluclate manually I just skip by the check.