Wish MC could define NoMaxBarsBack Variables

Questions about MultiCharts and user contributed studies.
bowlesj3
Posts: 2134
Joined: 21 Jul 2007
Has thanked: 209 times
Been thanked: 422 times

Wish MC could define NoMaxBarsBack Variables

Postby bowlesj3 » 18 Jul 2010

A wish list item.

Variiables:
NoMaxBarsBack MyVar(0),
NoMaxBarsBack IntraBarPersist MyVar2(0);

The new keyword I would like to see is "NoMaxBarsBack" for any variable we know does not need it.

Is there no way to tell MC not to set up a maxbarsback table for a variable (just like it can do for functions using simple and numericsimple).

I have a very large number of variables I set up that need only one occurance (no need to set up a maxbarsback table for these). And some of these are in studies that I have the maxbarsback purposely set at 1440 (two of my studies are like this). So it is setting up 1439 unused memory buckets for nothing and for every single work variable.

I have another study that each time I apply it to a chart the maxbarsback is set at 500 (that is at least 9 occurances of this study running in my workspace). So every work variable has 499 * 9 variable buckets which are a waste.

My guess is every study I have averages a good 10 to 20 work variables or more and never is there a [index] reference backwards. I know this will never happen when I define the variable. I am about to define 18 more work variables in one of my studies.

Maybe some day MC can get better than TS here.

janus
Posts: 778
Joined: 25 May 2009
Has thanked: 45 times
Been thanked: 93 times

Re: Wish MC could define NoMaxBarsBack Variables

Postby janus » 20 Jul 2010

Personally I prefer we got rid of the auto/manual maxbars feature altogether (or at least have the option to turn it off) and rely on an array based structure to provide the same results as you outlined. In other words if one wants to access historical data, the variable should be defined as a special array whereby the data is pushed back automatically as is the case now. So, using your method we would declare a variable thus:

Variables:
MaxBarsBack var1[100](0);

which means a variable called var1 will have at most 100 historical data values with var1 or var1[0] equal to the latest, var1[1] one bar back, etc. The study will use the largest value of all defined MaxBarsBack definitions to determine the largest "official" maxbarsback. Any reference made by the study outside the bounds will flag the same sort of runtime error message as does the now for accessing an array out of bounds, not try and re-run the study as is done now. Any variable not defined with a MaxBarsBack setting (and with the maxbarsback feature turned off) will only retain one value, namely [0]. I see many advantages in using this new approach. Of course I don't expect this to be done.

bowlesj3
Posts: 2134
Joined: 21 Jul 2007
Has thanked: 209 times
Been thanked: 422 times

Postby bowlesj3 » 20 Jul 2010

Hi Janus,

It is an interesting variation on my thoughts. I will give it some thought and comment further when I have a bit more time. However you are correct in that removing the MaxBarsBack processing from MC is unrealistc for TSS support to do. However I am guessing that a quick and dirty way to store special variables that have no maxbarsback may be more realistic which is one reason I bothered to create the thread. I am thinking that maybe they could somehow use the NoMaxBarsBack to trick MC into thinking this special variable is like a GV lookup which has no maxbarsback (but do this in a way that it is much faster than having to do a GV search which I suspect is a bit slow compared to getting and updating a regular variable).

The other question is, how much memory savings is there really considering the huge amounts of memory in computers these days and is it worth TSS putting out such an effort (also potentially putting users at risk of new bugs being created).

John.
Last edited by bowlesj3 on 20 Jul 2010, edited 1 time in total.

janus
Posts: 778
Joined: 25 May 2009
Has thanked: 45 times
Been thanked: 93 times

Postby janus » 20 Jul 2010

I'm not so concerned about the memory issue. I'm more concerned about how a complex study is forced to re-run with a larger maxbarsback just because I dare to reference say the close 100 bars back only when I'm already 10,000 bars into the data. Worse still is a study that looks back more and more as it moves along forcing the study to keep re-running. Then what happens in real-time if the study suddenly decides to reference data more bars back than ever before? Bang, it goes and re-runs the whole data again when it never needed to in the first place. It's not such a big issue now but I bet in the future when users develop really complex studies it will be. The solution I use is to store the quote data in dynamic arrays. That way I can reference data any way I wish without triggering a re-run.

bowlesj3
Posts: 2134
Joined: 21 Jul 2007
Has thanked: 209 times
Been thanked: 422 times

Postby bowlesj3 » 20 Jul 2010

Yes the reruns without notice is a problem at times until one does what they have to in order to deal with it.
You have found a solution that fits you. I have found one that fits me.

I personally will not likely ever exceed the maximum MaxBarsBack I have currently set and I have a system to detect it if it occurs using GVs (it is in the user contributed studies).

Indicators do not do this apparently because it could mess up orders.

janus
Posts: 778
Joined: 25 May 2009
Has thanked: 45 times
Been thanked: 93 times

Postby janus » 20 Jul 2010

I personally will not likely ever exceed the maximum MaxBarsBack I have currently set and I have a system to detect it if it occurs using GVs (it is in the user contributed studies).

Indicators do not do this apparently because it could mess up orders.
Looks like I should visit the user contributed studies forum more often. I wrote my own function to detect when a study is re-run.

I think you meant to say strategies do not do this. You bring up another thought. If strategies don't do it then why should indicators, or at least why not have the option to turn it off to be consistent? I'd go further and get rid of the distinction between indicators and strategies so we could remove the plot restriction from strategies, and other restrictions. It would also avoid a lot of duplicated coding and computations. I could never understand why there is the need to have the two types of studies. Perhaps this is the reason. If so then it could all have been avoided if there was the option to turn off the rerun in indicators. Too late now of course.

I did start using functions to avoid duplicating a lot of code but that initially failed miserably as I had to pass lots of parameters (around 50+). I got around this by passing my parameter values inside arrays so now it's much easier to manage. Still, there's the duplicated computations - such a waste for complex studies. I can assure you this issue will be a major hurdle for those who develop complex studies. However, when MC is 64-bit and computers get more powerful, this will be less of an issue. So, the sooner it becomes 64-bit the better.

The conclusion is EasyLanguage is fantastic for simple to medium level studies but fails miserably for very complex ones. There is an option to use DLLs so very complex computations can (and should) be executed outside of MC. However, there's still the issue of duplicate computations when one needs to plot an indicator and place orders through a strategy. It's possible to avoid this duplication by using GVs. The indicator does the computations (via a DLL) and the strategy picks up any necessary information from the indicator via GVs. The indicator must be executed first before the strategy, which may or may not be easy to control. All this is feasible but it's a shame we have to use such tricks in the first place. A better idea would be to make MC more object orientated so that a strategy can call an indicator, and have specific variables in the indicator defined as shared so the strategy can have access to them without the need to use GV statements implicitly in the code. I know - all this is too hard and unlikely to happen in the next few years, if ever.

User avatar
TJ
Posts: 7383
Joined: 29 Aug 2006
Location: Global Citizen
Has thanked: 996 times
Been thanked: 2113 times

Postby TJ » 20 Jul 2010

.... It would also avoid a lot of duplicated coding and computations. ....
it would be nice if PLOTs can be placed on 2 subcharts from the same indicator,
just like drawing objects.
That would save some of my coding.

bowlesj3
Posts: 2134
Joined: 21 Jul 2007
Has thanked: 209 times
Been thanked: 422 times

Postby bowlesj3 » 21 Jul 2010

LOL, Hey TJ, for the first time I noticed your cool glasses actually flash. That is the trivia for the day. Actually I just realized only one of them flashes. Fixing that is today's RFC to TSS.

So one study can put drawing objects on two subcharts. Didn't know that. Learn something every day.
I think you meant to say strategies do not do this.
Yes, I get the names mixed up. I think the official names are found when one enters "file + New" in the Power Editor. You get "new Study Type (function, indicator, signal)". So signal is the correct MC word. Maybe Strategy is a TS word. I guess I need to look this up when I type here. It seems that "function code", "Plot code" and "Order code"would be ideal to describe what you can do in them.

I think all our thoughts on what could be improved are good. The problem is MC (or is it actually and old TS being fixed up) would require a 90% rewrite from what I gather (nice to dream however). It makes absolutely no sense to me in any way shape or form to keep the MaxBarsBack tradition without the ability to to define variables that do not create these tables if one is writing a copy of TS EL which we call MC. I like the MaxBarsBack idea but only with some sort of an option to flip back and forth. Whoever limited it to just MaxBarsBack slipped into rut thinking for sure (pretty heavy blinders one might say). It happens to all of us from time to time and when it does we are not aware it is happening. But that is the purpose of a forum (to avoid it and harvest great anti rut thinking ideas). It is kind of like the MC version of the GetActive commands. Gee, I thought someone was incredibly smart to create the MC GetActive command to make it interactive and I was incredibly lucky to have stumbled on it. However it seems from what I am hearing now that I have stumbled on a great use for an error someone thought they made.

So considering TSS should not start a rewrite surely there is a way to set aside memory to get at simple variables and a way to warn us of the hidden recalculate occuring. But Maybe it is not so easy as I think it should be.

Regarding complex strategies, I am avoiding that and avoiding putting everything into the computer. At present I enter the waves and entry points myself and let MC and my program point out things I may not have noticed and edit to make sure I do not make any serious errors. If I do "error" it blocks my order but allows me to override if I wish. It is my way of balancing the strengths of the human mind and the computer. It is also more fun that way (for me at least). I believe in that old saying "too much of a good thing is a bad thing".

User avatar
TJ
Posts: 7383
Joined: 29 Aug 2006
Location: Global Citizen
Has thanked: 996 times
Been thanked: 2113 times

Postby TJ » 21 Jul 2010

LOL, Hey TJ, for the first time I noticed your cool glasses actually flash. That is the trivia for the day. Actually I just realized only one of them flashes. Fixing that is today's RFC to TSS.
I think there's a bad pixel on your monitor.

...JK
So one study can put drawing objects on two subcharts. Didn't know that. Learn something every day.
the following keywords draw on subchart #1, irrespective of where the indicator resides:
(add _s suffix for subminute)
ARW_NEW
TEXT_NEW
TL_NEW


the following keywords draw on any subchart it is residing in:
(add _s suffix for subminute)
ARW_NEW_SELF
TEXT_NEW_SELF
TL_NEW_SELF
Last edited by TJ on 22 Jul 2010, edited 4 times in total.

bowlesj3
Posts: 2134
Joined: 21 Jul 2007
Has thanked: 209 times
Been thanked: 422 times

Postby bowlesj3 » 22 Jul 2010

any subchart:
I always run the _self commands in a study that runs in subchart #2 (so far only TL_ and Arw_). My understanding (from what you said) is that the _self commands can run in a study that is based in subchart #1. Okay so assuming that is correct and if I have 2 subcharts and the _self command is running in a subchart #1 study how will I tell it to put a drawing in subchart #2 or subchart #3. Lets say one subchart is RSI and the other subchart is MacD.

User avatar
TJ
Posts: 7383
Joined: 29 Aug 2006
Location: Global Citizen
Has thanked: 996 times
Been thanked: 2113 times

Postby TJ » 22 Jul 2010

any subchart:
I always run the _self commands in a study that runs in subchart #2 (so far only TL_ and Arw_). My understanding (from what you said) is that the _self commands can run in a study that is based in subchart #1. Okay so assuming that is correct and if I have 2 subcharts and the _self command is running in a subchart #1 study how will I tell it to put a drawing in subchart #2 or subchart #3. Lets say one subchart is RSI and the other subchart is MacD.
"self" is self... in any subchart it is residing on...

bowlesj3
Posts: 2134
Joined: 21 Jul 2007
Has thanked: 209 times
Been thanked: 422 times

Postby bowlesj3 » 22 Jul 2010

Okay so currently what I do is I put the _self command in an Indicator that is isted in the "format objects" studies tab, as subchart #2 ... and .... I have found that as long as I have the scale set properly it will appear properly on that subchart #2.

It appears that my above description is the correct way to do it.

However, I had thought you meant that one could do this:
put the _self command in an Indicator that is isted in the "format objects" studies tab, as subchart #1 ... and .... somehow get it to appear in subchart #2 or even subchart #3 instead of the subchart where the study is allocated to.

I am now assuming this second idea can not be done and we just miscommunicated.

User avatar
TJ
Posts: 7383
Joined: 29 Aug 2006
Location: Global Citizen
Has thanked: 996 times
Been thanked: 2113 times

Postby TJ » 22 Jul 2010

...
I am now assuming this second idea can not be done and we just miscommunicated.

I have added clarification to my post above.


Note:
The _SELF series of keywords are MultiCharts specific.
With TS, you can only draw in the subchart that the indicator resides.

bowlesj3
Posts: 2134
Joined: 21 Jul 2007
Has thanked: 209 times
Been thanked: 422 times

Postby bowlesj3 » 22 Jul 2010

Okay, I see it now.

Only ever had TS4 EOD. Never used it much really and never knew it all that well (not compared to MC). Seems someone is still using it as mentioned by someone on the omega-list. I would have thought it was long gone. But then again it was having a date problem so maybe it has hit its lifes end.

User avatar
Dave Masalov
Posts: 1712
Joined: 16 Apr 2010
Has thanked: 51 times
Been thanked: 487 times

Re: Wish MC could define NoMaxBarsBack Variables

Postby Dave Masalov » 21 Sep 2011

If you are worried that variables, that are not series ones, use excessive RAM, your worries are in vain.

1) If the variable is not used as a series (the operator [] is not applied directly or indirectly to the variable and this variable is not a part of the statement, that in it’s turn is an argument of serial input of any function) it will be simple – consequently a buffer for history values storage with MaxBarsBack depth won't be created.

2) If the variable is not serial and its value is set after the last one has been just read, such a variable will be lite variable, i.e. the buffer for saving the last close value of the bar won't be created and the rollback operation won't be applied.

You may check the actual variable type (series or simple) after successful compilation of the study: place the mouse pointer on the necessary variable in editor window – hint window with actual type (for example: NumericSimple or NumericSeries) will be shown.

bowlesj3
Posts: 2134
Joined: 21 Jul 2007
Has thanked: 209 times
Been thanked: 422 times

Re: Wish MC could define NoMaxBarsBack Variables

Postby bowlesj3 » 21 Sep 2011

Thanks Dave,

I will run this info past my test scripts of the past to see if I can figure out how it connects with the results I was getting. I did that. See the next post. It has a few suggestions. One significant one is underlined.

John.
Last edited by bowlesj3 on 21 Sep 2011, edited 2 times in total.

bowlesj3
Posts: 2134
Joined: 21 Jul 2007
Has thanked: 209 times
Been thanked: 422 times

Re: Wish MC could define NoMaxBarsBack Variables

Postby bowlesj3 » 21 Sep 2011

Okay, I reviewed the tests I did. The main test was A_TestCnt (see link below that shows the tests). The A_TestCnt test was from the 2nd post to that thread. Yes I just took a look at it and it was numeric simple. I was not even aware of that. The mistake I was making is that I assumed that because each new tick was zeroing it out (when it does not have intrabarpersist) that it must be a numeric series item. After all logically, why should a new tick zero out a variable when it is a simple variable. So IntraBarPersist is the answer and it had nothing to do with series or simple. That is good to know. So I closed the Project Management item in regards to MaxBarsBack but I will create a new one requesting the following items pertaining to IntraBarPersist. I will copy them into the bug tracker with a slightly different wording as required.

There is the need for a way to warn new users about what happens without IntraBarPersist since it drives them crazy when they do not realize they have to put it on when "update on every tick" is used. So the best place to let the user know may be here. When a user checks "update on every tick" a WARNING popup box could tell them that in order for the variable to retain its value when a new tick comes in "IntraBarPersist" needs to be used. . However, at the same time maybe they should get an error if the compiler detects they are using IntraBarPersist for the ID of a Text_new Arw_new or TL_new. The reason you can not use IntraBarPersist as an ID for these commands is the object keeps getting removed until barstatus = 2 anyway and storing a number that might change the next time around causes problems (I made that mistake). So the warning would need to take them to a help to explain why. It needs to explain it by sending them to a help page that shows them the process. My link below explains that one too. It took me a long time to figure out what was going on. If a popup showed up every time a user used "update on every tick" and it took me to documentation and examples it would have saved a lot of time.

Also, I think that popup warning should also come up if they copy a script and that copy has the "update on every tick" checked off. As with all warning popups they should have a way to turn it off of course. Also a way to go back and find they ones they have turned off so they can turn them on again if they want (a string searchable list would be good) .

viewtopic.php?f=5&t=6871&p=29461#p29461

This request for TL_New_Persist is related to the fact that TL_new etc remove the object for each tick. If these commands are ever put in the ID will need IntraBarPersist when used with "update on every tick".
https://www.multicharts.com/pm/viewissu ... _no=MC-436

One more idea. Why not have your compiler give a popup when the user completes their variable definition, It would say "Do you want IntraBarPersist to ensure new ticks do not zero out this variable". It would save them typing and I will admit, I do not like typing IntraBarPersist over and over. I do not care much for having to cut and paste it too even though that is a bit faster. Obviously the compiler needs to know if this study runs as "execute on every tick". The problem with this idea is the TL_new problem. It has no way of knowing if this is the ID for a chart object creation command. Maybe the popup could include "Not recommended for variables that store the ID of TL_New, Text_New, Arw_new".

One last consideration. Consider a shortform for IntrabarPersist such as IBP. Most users will appreciate the reduction in typing.

I am going to zero in on the problem with IntraBarPersist. Experienced programmers and normal people learning programming will automatically assume that a variable (once set) will not be changed by something else. Their assumption makes perfect sense. The need for the inclusion of IntraBarPersist to do what is normal is not good. So I guess it is too late to remove IntraBarPersist but these ideas would help.

User avatar
Dave Masalov
Posts: 1712
Joined: 16 Apr 2010
Has thanked: 51 times
Been thanked: 487 times

Re: Wish MC could define NoMaxBarsBack Variables

Postby Dave Masalov » 23 Sep 2011

John,

Thank you for your suggestions, I will forward them to the developers. Also, in my previous post I meant to say: "If you are worried that variables, that are not series ones, use excessive RAM (and not CPU!), your worries are in vain". Sorry for the confusion.

bowlesj3
Posts: 2134
Joined: 21 Jul 2007
Has thanked: 209 times
Been thanked: 422 times

Re: Wish MC could define NoMaxBarsBack Variables

Postby bowlesj3 » 23 Sep 2011

Hi Dave,

Thanks for your help and the explanation.

As I said, I will try and put the suggestions into projection management maybe this weekend.

I do remember reading something about the NumericSeries allocation of variables when I did a sequential pass through the main manual. I could not remember all the details (mental overload most likely). It was an old TS manual I think. It probably did not mention that the cursor could be placed over the variable to show the result. I also think that at that time I did not know what Numericseries meant anyway. I guess I never noticed the popup when the cursor is over the variable (I will use it a lot now). LOL, I guess this is what most call "learning by experience" (meaning we realize that you can not learn it all on a single pass through a manual). And this is the main reason I feel you should place warnings about IntraBarPersist in strategic locations within your compiler/software. New users will not be able to grasp it if you just stick it in the manual. It needs a repeat at the very place they need to make the decision. None of this is for me. It is for new users. However I will say one thing. I have made the mistake of not using IntraBarPersist 2 times since I learned about it. Each time I would estimate I lost 2 hours figuring out what was wrong (inexperienced programmers could take longer and it would depend on the code complexity of course). So the idea of having the compiler ask every time if you want "IntraBarPersist" included would be very helpful to even an experienced user in terms of reducing debugging time as well as typing time. Now the error where I used IntraBarPersist on the ID of a Text_New and I stored that value for later manipulation really screwed me up (I vaguely remember this one taking literally days to figure out). And just figuring out that Text_New keeps deleting the text and replacing it I seem to remember about 3 weeks (full time). The code was very complex to start and this wrinkle was just driving me crazy (can not remember all the details now). Yes, it is an area that you need to document better. Actually Intrabarpersist was not in any of your documentation when I got MC 2.1.???.???. Someone told me about it later.

So I am going to split each "IntraBarPersist" suggestion into separate project management entries and link them too. I will also link the info to the Text_New_Persist as well.

Another idea for your manual. You might want to have a database link in each entry for 1 or more links to forum created examples of scripts and/or explanations. If you like someone else's example it could save you time creating your own.

John.


Return to “MultiCharts”