MaxBarsBack bug?  [SOLVED]

Questions about MultiCharts and user contributed studies.
guest

MaxBarsBack bug?

Postby guest » 24 Jul 2007

i have a strategy that references back 100 bars. i need to set the maximum number of bars study will reference to 150 to get the signal to work. is this a bug?

User avatar
Marina Pashkova
Posts: 2758
Joined: 27 Jul 2007

Postby Marina Pashkova » 27 Jul 2007

Could you please give us the script of the strategy you've been using? You can either post it on the forum or e-mail it to us.

Guest

guest

Postby Guest » 27 Jul 2007

just do this:

if rsi(close,100)>50 then buy 1 contract on close;

According to this code, the maxbarsback setting should be 100, but I need to set it to 150 for it to work.

User avatar
Marina Pashkova
Posts: 2758
Joined: 27 Jul 2007

Postby Marina Pashkova » 31 Jul 2007

What version of MultiCharts are you using?
The latest beta version does not have the problem you've described.

guest

Postby guest » 01 Aug 2007

2.1.928.1050

User avatar
Marina Pashkova
Posts: 2758
Joined: 27 Jul 2007

Postby Marina Pashkova » 01 Aug 2007

Well, the version you are using is the latest.
We haven't been able to reproduce your problem. We'll have to look at it via HelpDesk.
You could contact us through LiveChat, tell us briefly what the issue is and we will tell you what to do next.

ctrlbrk
Posts: 79
Joined: 18 Feb 2010
Location: Dallas, TX
Contact:

Postby ctrlbrk » 10 Mar 2010

Sorry to bring this thread back from the grave, but I have the exact same problem on MC 6.0 beta 2.

My signal requires 100 bars. I can find no way to increase the "maxbarsback" setting for a signal (only for a study).

I am new to EL, so if you could just give me the EL command.. seems like a simple "MaxBarsBack=100;" would do it, but nope.

Help please..

Mike

ctrlbrk
Posts: 79
Joined: 18 Feb 2010
Location: Dallas, TX
Contact:

Postby ctrlbrk » 10 Mar 2010

Sorry. I found it hiding under "costs/capitalization" section... not very intuitive, but found it nonetheless..

Mike

User avatar
Bruce DeVault
Posts: 438
Joined: 19 Jan 2010
Location: Washington DC
Been thanked: 2 times
Contact:

Postby Bruce DeVault » 10 Mar 2010

Both studies and signals have the capability of having a hard-specified max bars back. The main difference is studies also have the ability to auto-detect, while signals do not (mainly because sending real trades during the auto-detection process would be bad).

bowlesj3
Posts: 2180
Joined: 21 Jul 2007
Has thanked: 227 times
Been thanked: 429 times

Postby bowlesj3 » 10 Mar 2010

MC does auto detection by doing repeat recalculates (without telling you it does this) until it gets it correct. I can see why this would not be a good thing to do if a live trade is out there.

janus
Posts: 835
Joined: 25 May 2009
Has thanked: 63 times
Been thanked: 104 times

Postby janus » 10 Mar 2010

I wish there was a feature to turn of "maxbarsback" auto-detection completely. It's more often a pain for me as I like to reference data many hundreds of bars back. I check to make sure I don't reference back past the first bar. Even if it was turned off and the study tries to reference an invalid bar, it could abort with the same sort of error when one references outside the bounds of an array. By going back say 500 bars half way though the chart, the study thinks I will be doing it from bar 1 so it re-calculates, which is a waste since I have my checks anyway. Setting it manually is no point as I don't know what the maximum is, and it will change over time. So, I resorted to using dynamic arrays to store the data. That frees me to do whatever I want. For example, I could be near the end of the data and reference all the way back to the first bar and the study won't go berserk and do it's auto-detect thing. Downside of course is the study slows down a little and uses more memory. Small price to pay as it's worth it.

User avatar
Bruce DeVault
Posts: 438
Joined: 19 Jan 2010
Location: Washington DC
Been thanked: 2 times
Contact:

Postby Bruce DeVault » 10 Mar 2010

There are plenty of platforms that do work the way you're describing (NeoTicker, NT come to mind) in that they don't set aside a particular number of "startup" bars and prohibit looking back past that - rather, everything starts on bar #0 and you can look all the way back to the beginning of the series (although NT 7 has now made that optional). But, this comes at a cost, which is that all series created such as for indicator calculations go all the way back to the start of the chart, and for small bars and many days of data loaded, it is actually possible to exceed the 2GB memory limit for 32 bit applications in this manner. An ideal platform in this regard would give the option to do it either way, but that would require probably more intelligence and foresight on the part of the programmer to use this properly unless it defaulted to something like the current behavior with auto-detect.

janus
Posts: 835
Joined: 25 May 2009
Has thanked: 63 times
Been thanked: 104 times

Postby janus » 10 Mar 2010

Yes, I know most other platforms do it the other way. Your explanation as to why MC limits how far back one can look at first looks reasonable. However, how does MC get around it when one displays huge slabs of price and volume data on a screen? Does it access the data direct from the database? If so, then why can't the study do it also, at least after a certain range (ie, cache a certain amount back like it does already, then access the data direct from the database thereafter)? Anyway, I'm using my own arrays and it works fine. Things are back to front compared to the usual data[] syntax, that is arrayn[1] is the first bar and arrayn[currentbar] is the last one. I have a traditional mathematical background so I actually prefer it this way of referencing data. Each to their own. At least MC gives me the flexibility of doing it this way. If it didn't, I wouldn't be using MC in the first place.

User avatar
Bruce DeVault
Posts: 438
Joined: 19 Jan 2010
Location: Washington DC
Been thanked: 2 times
Contact:

Postby Bruce DeVault » 10 Mar 2010

In platforms like TS/MC with a "maxbarsback" style architecture, the bars are all loaded onto the chart and are accessible for the charting engine, but they're just not accessible programmatically. Similarly, all of the plot outputs of studies are kept for every bar (which is why they can be scrolled to without recalc, and appear in data view) but they can't be referenced that far back. The reasons likely have to do with a desire for simplicity in the way it's implemented, to make sure that all series are treated in a consistent manner. It does seem likely that some strategic additions could be made to make it possible to address further back, but a lot depends on how the data is stored, etc. and the ease of doing this is a question only the developers could elaborate on with rigor.

janus
Posts: 835
Joined: 25 May 2009
Has thanked: 63 times
Been thanked: 104 times

Postby janus » 10 Mar 2010

The solution I proposed is just one of several. However, it's of little consequence as I have it working the way I like it and I can reference data going back as far as I like. With PCs getting faster and faster, the delay introduced in using dynamic arrays is not a problem. One side benefit is I can set the "maxbarsback" manually to a very small value and the study hardly ever has to re-calculate thus saving time there. Memory might be an issue but that's another problem that MC should fix - the limit is too low given we now have 64-bit systems that can address many 10's of GB if not much more limited by the cost, unless that's been fixed in 6.0.

bowlesj3
Posts: 2180
Joined: 21 Jul 2007
Has thanked: 227 times
Been thanked: 429 times

Postby bowlesj3 » 11 Mar 2010

I am curious what it is about your strategy that requires you go back all the bars. I thought I was high in using 1000 for maxsbarsback on two of my studies and 500 on some of the others. I am thinking of writing print statements with the offsets I am using and having a program read then in to find the max I have ever used. However I don't think 1000 is to big a memory draw so I question if it is worth the effort.

janus
Posts: 835
Joined: 25 May 2009
Has thanked: 63 times
Been thanked: 104 times

Postby janus » 11 Mar 2010

I am curious what it is about your strategy that requires you go back all the bars. I thought I was high in using 1000 for maxsbarsback on two of my studies and 500 on some of the others. I am thinking of writing print statements with the offsets I am using and having a program read then in to find the max I have ever used. However I don't think 1000 is to big a memory draw so I question if it is worth the effort.
Let's say a study looks back a few periods every so often then suddenly near the end it looks back 100 periods. The study re-starts and re-calculates a new value to look back. This may happen several times, so it slows down the study too much. I could set it manually but then I never know what the value should be since it can vary with different parameters. I could set it to 1000 but then I may need to look back more than that - I just know. One of my studies for example looks back to see where the major support and resistance levels are, then looks at the patterns near there using magnitude and time based swings to gauge the importance and ranking of that level. I have thought of making the code more sophisticated to store all the required information in arrays as I go to avoid looking back, but then I keep finding I need more information thus making the code too complicated than it needs to be. So, I rather use the simple approach and store the raw data in arrays and be free to do whatever I like. I can then focus on the trading rules and not so much on fancy coding. After all, I want the computer to do most of the work, not me. I rather focus on the trading rules, not try to make the study run at peak performance.

User avatar
Bruce DeVault
Posts: 438
Joined: 19 Jan 2010
Location: Washington DC
Been thanked: 2 times
Contact:

Postby Bruce DeVault » 11 Mar 2010

Many things, like let's say an oscillator, have a deterministic number of bars required to calculate. Other things, like let's say the high price of all time, could be tracked using no bars on a "going forward basis" by simply keeping track of what the current so far high is, and every time it's broken, noting that price. But there are yet other things that could require going further back or tracking in a custom array structure. An arbitrary made up example of this would be that every time there's a new swing high, you want to find the previous swing high that's highest but less than this one, and see if that's within 10 ticks of the current one. To do that, you can't necessarily know how far back you must go so you either need (a) the ability to go all the way to the start of the data you have either in the platform or by making your own copy of the data in an array, or (b) you could be slightly smarter about it, and track just the highs in your array. While this example may be arbitrary, there are a lot of similar sorts of calculations that aren't.

bowlesj3
Posts: 2180
Joined: 21 Jul 2007
Has thanked: 227 times
Been thanked: 429 times

Postby bowlesj3 » 11 Mar 2010

You are basically doing the same as I except I find those swings visually and input the info via arrow drops using binary searchs to get the info I want. From a maxbarsback perspective it is the same doodoo just a different day. I get notified by the binary search routine if I exceed the maxbars back and being discretionary I am suppose to just increase it (I don't care if my study flips out on me since it restarts with GV info anyway). Before I reworked the binary routine it would just go all the way back to the start of the chart and force the recalulate and I would not know. It would set it way too high at 7000 or something. It sounds like I do not need as high a setting because when the support is farther back I just jump to a higher bar size (5minutes up to 60 minute bars). That may be because I am doing it visually.

janus
Posts: 835
Joined: 25 May 2009
Has thanked: 63 times
Been thanked: 104 times

Postby janus » 11 Mar 2010

(b) you could be slightly smarter about it, and track just the highs in your array. While this example may be arbitrary, there are a lot of similar sorts of calculations that aren't.
I do this already - I store specific information about the turning points, such as the bar number, high/low and magnitude/rank, but I still need to perform other work at the surrounding bars only when necessary. One could spend a lot of time developing much more fancy code but I rather spend the time trading and let the computer do most of the work using the raw arrays supplemented by a special "information" array.

User avatar
Bruce DeVault
Posts: 438
Joined: 19 Jan 2010
Location: Washington DC
Been thanked: 2 times
Contact:

  [SOLVED]

Postby Bruce DeVault » 11 Mar 2010

Yes, it's always a trade off of spending more time and code making something that runs slightly faster etc. vs. just brute force solving the problem. While there's much to be said for elegant coding, computers get faster every year, and often there are more important things to do than speed something up by 5% such as focusing on getting a better answer and not just getting the same answer faster.


Return to “MultiCharts”