persistence scope of variables within a study

Questions about MultiCharts and user contributed studies.
RWDickinson
Posts: 43
Joined: 01 Dec 2008
Has thanked: 2 times
Been thanked: 2 times

persistence scope of variables within a study

Postby RWDickinson » 05 Dec 2008

I am having a problem with variables being randomly reset by MC between entries to my code (i.e. between bars). I thought all variables were persistent, but it seems not. The variables I use need to be persistent only within a single indicator or strategy, not sharing among strategies (I think this is what Global Variables is intended for). IntraBarPersist says it is for variables being updated on every tick, which is not my case, so that doesn't seem relevant either. I need a variable set during one run of my indicator to have that same value on the next run, i.e. on the next bar. How do I do this?

User avatar
TJ
Posts: 6609
Joined: 29 Aug 2006
Location: Global Citizen
Has thanked: 971 times
Been thanked: 1912 times

Postby TJ » 05 Dec 2008

if you have a value1 = c, then every time c changes, value1 changes.

if you want the value1 as of the end of previous bar, then use value1[1].

RWDickinson
Posts: 43
Joined: 01 Dec 2008
Has thanked: 2 times
Been thanked: 2 times

Postby RWDickinson » 05 Dec 2008

Thanks, TJ. My question is more like:

Vars: abc (0);


<code.......>
if abc < something then begin
.....
end;

under some other condition begin
abc = something
end


I need the value of abc to be persistent across multiple runs of the program, i.e. after i set the value during one bar, it must have the same value when I enter at the next bar. My experience is that sometimes the value is still there, sometimes it has been reset by MC to its default value (0).

Is that clearer? Or is this the question that you answered and I haven't understood you?

User avatar
TJ
Posts: 6609
Joined: 29 Aug 2006
Location: Global Citizen
Has thanked: 971 times
Been thanked: 1912 times

Postby TJ » 05 Dec 2008

Vars: abc (0); sets the initial value.

from that point on, the program takes over.

the program assigns it whatever value your codes decides.


I have never experienced MC resetting a variable to its initial value in mid-session.


someone can let us know if he has experienced the same as you.

bowlesj3
Posts: 2028
Joined: 21 Jul 2007
Has thanked: 174 times
Been thanked: 405 times

Try barstatus

Postby bowlesj3 » 05 Dec 2008

Question, do you have the study set to execute on every tick? If intrabar persist is not included it resets the variable on every new tick except the last tick. The variable is stored in element zero in a table the size of your max bars back setting. This table is either a roll around table or is actually shifted backward on each new bar.

Try including a print statements to debug along with using the barstatus command to try and figure out exactly on what tick it is getting set to zero. You can even count the ticks inside the bars using a counter which has the intrabarpersist statement. For the most part intrabarpersist does retain the variable settings. However I have experienced some resets (maybe 3 in the last 6 months if that). These days I avoid touching my EL code since it seems to be running okay.

Global variables retain their value until the machine reboots unless something strange happens with windows (on extremely rare occasions I have seen them loose values but this was caused by a very large number of aborts in my database program while testing new code - not MC.). So if MC aborts you can restart it and the GVs should still have the values. Obviously you can shut a study off and turn it back on and the GV values will still be there.

rsi77
Posts: 11
Joined: 03 Dec 2008
Location: Chicago

Postby rsi77 » 07 Dec 2008

I am having the same problem as described above. One of my variables is being set to a certain value within a loop. Once the value has been set the loop is not re-entered again. However, the variable retains its proper value for only a single bar, then it reverts to another value. There is only 1 statement within the code which assigns a value to this variable, and that statement is within a loop which closes once the assignement is made. Why does it set to a different value--how is this possible.

I am also having another problem (perhaps related):
I am using IOG. When I read the documentation for "intrabarpersist" it states that you should use this statement only when you wish for the variable to be updated on every tick. I only want my variable updated at the end of the bar so I do not use intrabar persist. However, I noticed that I was getting some strange results which seemed to indicate that variable were getting updated every tick. I solved the problem by placing an IF statement ahead of a series of assignments which said IF Barnumber <> Barnumber [1] BEGIN...etc. This seemed to solve the problem, which would seem to indicate that my variable were getting updated every tick.

In my strategy I wanted the entry to be based on closed bars, but I wanted my stops and targets to trigger intrabar.

Thanks for any help that can be offered.

rsi77
Posts: 11
Joined: 03 Dec 2008
Location: Chicago

Postby rsi77 » 07 Dec 2008

I did some troubleshooting and found that the variable resets once the code starts from the top of the strategy. I placed a Print statement for the line number and the variable value at the very end of the strategy and also at the very beginning. The value is correct at the very end of the startegy, but it resets to some arbitrary value (not 0) at the beginning of the strategy. This is very odd to me.

SUPER
Posts: 624
Joined: 03 Mar 2007
Has thanked: 99 times
Been thanked: 80 times

Postby SUPER » 07 Dec 2008

Under IOG mode, I have been given to understand that conflict can happen between variables declared as intrabarpersist and variables calculated once per bar (non-intrabarpersist) . TS support was able to demonstrate this behaviour with a sample code they sent me few weeks backs and the suggestion was to declare all variable as intrabarpersit.

bowlesj3
Posts: 2028
Joined: 21 Jul 2007
Has thanked: 174 times
Been thanked: 405 times

Postby bowlesj3 » 07 Dec 2008

Sorry guys. Found it via a forum search. IOG is Intrabar Order Generation. I do myne through a database program so I guess that explains my not knowing it.

I have not tested this yet in such precision but below is my understanding of what intrabarpersist off then intrabarpersist on does in a typical programmers benchcheck format. Maybe this format would be good for TS-Support to put in their manual. It helps the trader visualize what is going on.

When I say "EL code" I am refering to what EL does under the hood that the trader has no control over. For the EL code that the trader writes I am using the term "Your Code".

Code: Select all

No IntraBarPersist on VariableA
-----------------------------------
Bar Tick VariableA[1] VariableA[0] Any code that effects VariableA[0]
-------------------------------------------------------------------------
1   last      N/A             888 (assigned by your code on barstatus=2)
2   First     888               0 (assigned by EL code before the study)
2   Middle    888               0 (assigned by EL code before the study)
2   last      888             888 (assigned by EL code before the study)


With IntraBarPersist on VariableA
-----------------------------------
Bar Tick VariableA[1]  VariableA[0] Any code that effects VariableA[0]
-------------------------------------------------------------------------
1   last      N/A              888 (assigned by your code on barstatus=2)
2   First     888              888 (assigned by EL code before the study)
2   Middle    888              888 (Left as is by the EL code)
2   last      888              888 (Left as is by the EL code)


So with IntraBarPersist off, after your first tick comes into bar 2 and after all subsequent ticks execpt the last tick of bar 2, any attempts to change VariableA will be overwritten by the underlying EL code which executes before the next run through your study. So thus it is better to use IntraBarPersist on all variables and use the BarStatus to control stuff you want to do at the very end of the bar or at the very start of the bar (it documents your code too somewhat).

What is ammusing is I wrote all my main code without even knowing there was an intrabarpersist command or barstatus command and I managed to get it to work with updates on every tick. That is why I am afraid to touch my code now. I thought I understood why it worked but now that I am aware of the above I don't really understand why it works. However, it isn't broken so just leave it alone :-) New code is different. I use the commands now.

John.
Last edited by bowlesj3 on 07 Dec 2008, edited 1 time in total.

rsi77
Posts: 11
Joined: 03 Dec 2008
Location: Chicago

Postby rsi77 » 07 Dec 2008

Under IOG mode, I have been given to understand that conflict can happen between variables declared as intrabarpersist and variables calculated once per bar (non-intrabarpersist) . TS support was able to demonstrate this behaviour with a sample code they sent me few weeks backs and the suggestion was to declare all variable as intrabarpersit.


I am not using any intraperpersist statement in my code. I'm trying to figure out why the value of one of my variables changes between the last line of code and the first line of code. Why does this happen, and why does it happen only sometimes?

Can somebody who knows please hlep me?

User avatar
TJ
Posts: 6609
Joined: 29 Aug 2006
Location: Global Citizen
Has thanked: 971 times
Been thanked: 1912 times

Postby TJ » 07 Dec 2008

I am not using any intraperpersist statement in my code. I'm trying to figure out why the value of one of my variables changes between the last line of code and the first line of code. Why does this happen, and why does it happen only sometimes?
Can somebody who knows please hlep me?

it might help if someone can provide a generic code that demonstrate this problem. I am dying to find out what, where, when, why and how.

bowlesj3
Posts: 2028
Joined: 21 Jul 2007
Has thanked: 174 times
Been thanked: 405 times

Postby bowlesj3 » 07 Dec 2008

To me it is all explainable until rsi77 said the values are not set back to zero but rather are set to random numbers at random times. When you leave out intrabarpersist the values are always set back to zero at the start of each new tick (it never fails, I remember now, I did precise tests and I could find the thread if someone wants me to find it). I think your going to have to attach the code rsi77.

Sorry guys. Found it via a forum search (almost as good as google!!!!). IOG is Intrabar Order Generation. I do myne through a database program so I guess that explains my not knowing it.
Last edited by bowlesj3 on 07 Dec 2008, edited 1 time in total.

bowlesj3
Posts: 2028
Joined: 21 Jul 2007
Has thanked: 174 times
Been thanked: 405 times

Maybe this.

Postby bowlesj3 » 07 Dec 2008

The only thing I know of that can change a variables number randomly is when using the variable to recieve the number from a Text_new/Arw_new or TL_new statement. It occurs if you have more than one of these statements feeding the same chart and because the MC EL deletes these on every new tick and reissues the command because of timing issues it can end up running the command creating a different ID number because one of the other commands used that number between the delete and the recreate of the text.

rsi77
Posts: 11
Joined: 03 Dec 2008
Location: Chicago

Postby rsi77 » 07 Dec 2008

OK Guys, I'll post the pertinent code. In the first section below I assign a value to "StopLoss_Short" only after all the conditions for entry have been fulfilled. There are no other assignments to the variable "StopLoss_Short" outside of the code I've posted below. There are 3 loops which contain the assignement statement, and only one or none of them can be accessed in a given case since they each require a distinct value of the input variable "HowAggressive". In the particular case I'm focussing on all the requirements for a short entrhy exist, and in fact a short entry is taken. The stoploss_short variable is properly assigned the correct value as the print statments show. This correct variable is maintained through the end of the code as is seen by the output through line 213. But when I go back up to the top of the code, directly after the "VAR" and "INPUT" statements I have a new value for my StopLoss_Short variable. This new value prevents me from getting out of a trade that goes strongly against me. ...
First the section of Code where the stoploss is assigned--I have noted the particular loop which is entered in the particular case under study:

{Possible Filters include Stoch_Filter, Filter_3X, VerySlow_Filter and UseKC.}
{We will now determine if to enter based on which filters are activated.}
LookLong=0;
LookShort=0;
IF MP=0 THEN BEGIN
IF Fast[1]>Slow[1] THEN BEGIN
IF Stoch_Filter=0 THEN BEGIN
Fast_Stoch=1;
Slow_Stoch=1;
IF Filter_3X=0 THEN TripX=1;
IF VerySlow_Filter=0 THEN Fil_VS=1;
IF Fil_VS=1 THEN BEGIN
IF TripX=1 THEN BEGIN
IF Slow_Stoch=1 THEN BEGIN
IF Fast_Stoch=1 THEN BEGIN
LookLong=1;
IF HowAggressive=1 AND H[1]<Fast[1] THEN BEGIN
BuyStp=H[1]+TickValue;
Buy ("CnsrvLE") Next BAR NumCntrcts Contracts at BuyStp Stop;
Print(Date, " ",Time," ",H, " ",L," ",C," ","StopLoss_Long=",StopLoss_Long, "just placed buy order");
StopLoss_Long=Lowest(L,3)-TickValue;
Print(Date, " ",Time," ",H, " ",L," ",C," ","StopLoss_Long=",StopLoss_Long, " just defined stoploss in buy loop");

END;
IF HowAggressive=2 AND C[1]<Fast[1] THEN BEGIN
BuyStp=H[1]+TickValue;
Buy ("AggLE") Next BAR NumCntrcts Contracts at BuyStp Stop;
StopLoss_Long=Lowest(L,3)-TickValue;
END;
IF HowAggressive=3 AND L[1]<FAST[1]
THEN BEGIN
BuyStp=H[1]+TickValue;
Buy ("VAggLE") Next BAR NumCntrcts Contracts at BuyStp Stop;
StopLoss_Long=Lowest(L,3)-TickValue;
END;
END;
END;
END;
END;
END;
END;
IF Fast<Slow THEN BEGIN
IF Stoch_Filter=0 THEN BEGIN
Fast_Stoch=-1;
Slow_Stoch=-1;
IF Filter_3X=0 THEN TripX=-1;
IF VerySlow_Filter=0 THEN Fil_VS=-1;
IF Fil_VS=-1 THEN BEGIN
IF TripX=-1 THEN BEGIN
IF Slow_Stoch=-1 THEN BEGIN
IF Fast_Stoch=-1 THEN BEGIN
LookShort=1;


{NOTE--THIS IS THE LOOP THAT IS ENTERED}

IF HowAggressive=1 AND L[1]>Fast[1] THEN BEGIN
SellStp=L[1]-TickValue;
SellShort ("CnsrvSE") Next BAR NumCntrcts Contracts at SellStp Stop;
Print(Date, " ",Time," ",H, " ",L," ",C," ","StopLoss_Short=",StopLoss_Short," Just placed sell order");
StopLoss_Short=Highest(H,3)+TickValue;
Print(Date, " ",Time," ",H, " ",L," ",C," ","StopLoss_Short=",StopLoss_Short, " Just defined StopLoss");

END;

{END of LOOP WHICH HAS BEEN ENTERED IN THIS PARTICULAR CASE}

IF HowAggressive=2 AND C[1]>Fast[1] THEN BEGIN
SellStp=L[1]-TickValue;
SellShort ("AggSE") Next BAR NumCntrcts Contracts at SellStp Stop;
StopLoss_Short=Highest(H,3)+TickValue;
END;
IF HowAggressive=3 AND H[1]>FAST[1] THEN BEGIN
SellStp=L[1]-TickValue;
SellShort ("VAggSE") Next BAR NumCntrcts Contracts at SellStp Stop;
StopLoss_Short=Highest(H,3)+TickValue;
END;
END;
END;
END;
END;
END;
END;
PRINT("line207", " StopLoss_Short=",StopLoss_Short);
END; {End "IF MP=0"}
END; {End "IF Barnumber...}
END; {Time <>, etc}
END; {End DayCount > 7}

PRINT("line213", " StopLoss_Short=",StopLoss_Short);

END OF CODE:

Now I will show the result of the print statements after a short has been entered:



1081204.00 1128.00 862.00 862.00 862.00 StopLoss_Short= 873.00 Just placed sell order

{at the time the short is entered there is a value of 873 assigned to the variable "StopLoss_Short"}


1081204.00 1128.00 862.00 862.00 862.00 StopLoss_Short= 864.00 Just defined StopLoss

{In the next line a new value is assinged to the variable "StopLoss" based on the local high + 1 tick}


line207 StopLoss_Short= 864.00
line213 StopLoss_Short= 864.00

{The correct value remains assigned to "StopLoss_Short" through the end of the code}


line28 StopLoss_Short= 873.00

{But at the very beginning of the code (line 28 is directly after the Var and Input statements) a new value has been assigned to "StopLoss_Short". This is the same value which had been assinged to it prior to the last assignement....??????} :( :?: :?:

bowlesj3
Posts: 2028
Joined: 21 Jul 2007
Has thanked: 174 times
Been thanked: 405 times

When to not use intrabarpersist.

Postby bowlesj3 » 07 Dec 2008

Question? do you have the study executing on every tick (the checkbox on the parameters). I think that if you have it checked to NOT (NOT) execute on every tick that it is likely the same as only having it execute on the last tick (barstatus=2). So this senario is the only time that you do not need to use intrabarpersist. If you have it executing on every tick then you should be using intrabarpersist. This is what amazes me about my code. It works and I have it checked to run on every tick but I am not using intrabarpersist.

Summary:
if executing on every tick use intrabarpersist.
If not executing on every tick (only on last tick) then do not use intrabarpersist.

The thing is that you must be executing on every tick since you said you were using IOG (intrabar order generation).


The other thing is we would need to see the print statement at the top of the code that shows that your variable is getting set back to the first value before your code is getting executed the next time around (either on the next tick or on the next end of bar tick). If you don't have that print statement up there with some sort of marking to identifiy it how do you know for sure the code is not just executing again to reset it to the first value?

John.

bowlesj3
Posts: 2028
Joined: 21 Jul 2007
Has thanked: 174 times
Been thanked: 405 times

Postby bowlesj3 » 07 Dec 2008

you probably need more print statements too. I have been known to use a print statement on every single possible branch possible in my EL code to essentially create a very detailed trace.

Another thing is you can create a variable that would be a tick count which does have intrabarpersist on it and this should be in every print statement along with the bar time too so you can really see exactly where things are going within your code.

I think that there is a logic problem causing this. There is no way that the EL code can set your value to something so precise as a previous value. It has to be in the logic and a heavy use of well thought out print statements (that often evolve as you get more information too) is the old way to figure it out.

rsi77
Posts: 11
Joined: 03 Dec 2008
Location: Chicago

Postby rsi77 » 07 Dec 2008

OK, see below. I added a print statement at the very first line...the value has changed from the last line of code to the first line of code. There are not statements in between. I am set to IOG, but this should not require any extra code on the parameters unless I don't want it to execute IOG. As far as I can tell from the explanation the intrabarpersist is used to insure that your code DOES process every tick. I don't want that to happen except when exiging the trade...but in any case it doesn't explain a change in the value of a varialbe from the last line of code to the first line of code.

Is it not true in MC that variable values are maintained once the strategy has been started as they are in TS, or are they supposed to get set back to zero every time? In my case neither one is happening. The variable is the same before and after the "Var" statemement, it only changes betweent the last and first line of code, and it's not reset to 0, it's reset to some other value.

1081204.00 1128.00 862.00 862.00 862.00 StopLoss_Short= 873.00 Just placed sell order
1081204.00 1128.00 862.00 862.00 862.00 StopLoss_Short= 864.00 Just defined StopLoss
line207 StopLoss_Short= 864.00
line213 StopLoss_Short= 864.00
line1 StopLoss_Short= 873.00
line28 StopLoss_Short= 873.00
line36 StopLoss_Short= 873.00

Note that the print statement on line 213 is the very last line of code, and obviously line 1 is the very first line of code.

bowlesj3
Posts: 2028
Joined: 21 Jul 2007
Has thanked: 174 times
Been thanked: 405 times

Postby bowlesj3 » 07 Dec 2008

No, the intrabarpersist documentation is misleading. The name of this command is actually better. It means to persist in holding the value of your variable even though a new tick has come in. Inotherwords do not set the value back to zero on the next tick. Stay persistent with its current value.

Maybe I should not relay on my memory here. I did some tests and posted them here. I will go back and find them and bring them in to this topic.

John.

bowlesj3
Posts: 2028
Joined: 21 Jul 2007
Has thanked: 174 times
Been thanked: 405 times

Maybe this will help.

Postby bowlesj3 » 07 Dec 2008

Here is the post.

http://forum.tssupport.com/viewtopic.ph ... highlight=

I did some testing. There is a set of code in there that has print statements with the word "here" in them and they are offset to make it very clear to read them. Let me study what I did a little more. It has been a while.

John.

bowlesj3
Posts: 2028
Joined: 21 Jul 2007
Has thanked: 174 times
Been thanked: 405 times

Postby bowlesj3 » 07 Dec 2008

Yah, if you read through the whole post and see my example code and the print statements it shoud make it clear.

I have a post in there shortly after RobotMan pointed out the intrabarpersist and barstatus commands.

Run that code with execute on every tick checked on.

John.

bowlesj3
Posts: 2028
Joined: 21 Jul 2007
Has thanked: 174 times
Been thanked: 405 times

Postby bowlesj3 » 07 Dec 2008

Maybe you haven't found the proper method of controlling if your study is run on every tick or if it is run as I assume is the last tick of the bar.


Here is how it works:
You right click on the code and click properties at the bottom the click the properties tab at the top then check or uncheck the box "update on every tick". This will set the default for that code which is applied when you first place it into a chart for execution. Now you can apply this study to say 5 charts and go back to some of these charts and change them to execute with the other setting by doing this. Right click the chart, click format studies, highlight your study, click format, click properties, then select what you want on "Update on every tick". Again this does not change the default setting but rather only the execution of this study on this particular chart.


Another interesting thing to try would be to run your study with this checkbox set to not run on every tick and put in a print statement of the value of barstatus to see if it is always a value 2. I have never done this.

John.

bowlesj3
Posts: 2028
Joined: 21 Jul 2007
Has thanked: 174 times
Been thanked: 405 times

Postby bowlesj3 » 07 Dec 2008

I noticed a command in the help today that may be helpful. It is called "ticks". Here is a cut and paste from the help.

Code: Select all

TICKS

Returns the total number of ticks for the current bar if Build Volume On is set to Tick Count.
Returns the total volume for the current bar if Build Volume On is set to Trade Volume.

With Build Volume On is set to Tick Count:

   - the value of 1 will be returned for 1-tick charts
   - the total number of ticks in the current bar will be returned for multi-tick, volume, and time-based charts

With Build Volume On is set to Trade Volume:

   - the volume of the current tick will be returned for 1-tick charts
   - the total volume of the current bar will be returned for multi-tick, volume, and time-based charts

Please note that most data feeds provide only a limited history of tick and volume data; storing real-time feed data will ensure the availability of historical tick and volume data. Usage

Ticks Examples

Plot the number of ticks in the current bar (Build Volume On is set to Tick Count):
Plot1(Ticks,"Ticks");

Plot the volume of the current bar (Build Volume On is set to Trade Volume):

Plot1(Ticks,"Volume");

rsi77
Posts: 11
Joined: 03 Dec 2008
Location: Chicago

Postby rsi77 » 08 Dec 2008

OK, I'm still not totally understanding everything that's been explained here, but I did get the strategy to work using intrabarpersist and barstatus. For now I'm satisifed but I don't totally get how it works. I'll keep pondering it. Thanks for the help.

bowlesj3
Posts: 2028
Joined: 21 Jul 2007
Has thanked: 174 times
Been thanked: 405 times

Postby bowlesj3 » 08 Dec 2008

Great! Glad it worked out.

I am going to create a new post with a suggestion for TS-Support and reference that thread which has the test I created.

John.

rsi77
Posts: 11
Joined: 03 Dec 2008
Location: Chicago

Postby rsi77 » 08 Dec 2008

just for eveyone's information I will briefly explain what I did.

I wanted my buy/sell signals to be based on indicators which were based on completed bars only. In order to achieve this a placed all indicator calculations in an IF statement as follows:

IF BARSTATUS(1)=2 THEN BEGIN
Calculate indicator 1;
Calculate indicator 2;
Etc.;
HighOfBar = H;
LowOfBar = L;
CloseOfBar = C;
END;

All of the variables which were assigned values based on the indicator calculations were defined with "intrabarpersist". The reason I defiend HighOfBar, LowOfBar, etc. is so that while in my entry section of code the entry's could be based on a break of the high or low of the last bar. I also used the Close of the last bar relative to a moving average to determine whether or not to enter. Thus the variables "HighOfBar", "LowOfBar", etc. were defined with intrabarpersist.

This allowed me to enter and exit a trade on the same bar if both the trigger and then the stop were hit before the bar closed.

I hope this is clear. If there's a better way to do it some please speak up, but this way worked for me.

8) Good Luck


Return to “MultiCharts”