Big changes for MT4, in a few weeks - page 267
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
Aren't you losing on precision for only 100 bars?
No. Transient Zones its doschian channel showed as S/R. In my EA I only need last 2 TZs for send signals
No. Transient Zones its doschian channel showed as S/R. In my EA I only need last 2 TZs for send signals
And what about different indicators (ema being one of the examples)?
And what about different indicators (ema being one of the examples)?
Every indicator have limits. For example in NonLagMA I have use a prerroll for bars for algorithm get right values in init stage. But in tick event you don't need calculate many bars in almost all indicators. I commented to Madlen if he can add bars option to his indicators but he think is not useful. It's evident he don't try load 56 NonLagMAs at same time. I sent report to metaquotes because this kill MT4 ( out of memory ). It's not indicator guilty but if you can down bars to work in indicators is better...
Every indicator have limits. For example in NonLagMA I have use a prerroll for bars for algorithm get right values in init stage. But in tick event you don't need calculate many bars in almost all indicators. I commented to Madlen if he can add bars option to his indicators but he think is not useful. It's evident he don't try load 56 NonLagMAs at same time. I sent report to metaquotes because this kill MT4 ( out of memory ). It's not indicator guilty but if you can down bars to work in indicators is better...
braintheboss
As I explained : my indicators calculate maximum 3 bars 99.9999% of time. They could do with 2 bars on new ticks, but I prefer to calculate 3 bars (saw some examples that convinced me to do so). So there is no need at all for any "bars limitation".
As of "loading 56 NonLagMAs at a same time" : I believe that with 100K bars on a chart and with nnn charts, any trading platform will give up. Try tradestation (which is the standard for [professional trading terminals) and you shall see the same thing. Limit your charts to reasonable number of maximum bars (I never use more than 5000 bars per chart, not in the last 7-8 years of live trading, and never had any problem with that) and then try the "56 instances" - the new tick will not cause the issue, what will cause the issue is the memory usage of buffers used from indicators, but no internal limit to some maximum bars calculated in indicator will change anything regarding that when the buffer is allocated for the full chart history. There will be no change whatsoever in cases like that
___________________
So, please check what is the result of some calculations (take a simplest jurik calculation when you limit the number of calculated bars and compare it to the result with same parameters but using the whole history) and what is the real number of calculated bars in a correctly coded indicators on new ticks and then, please, check the above mentioned "issues".
___________________
PS: I did my share of testing too. The simplest price retrieval made as a class and made as a function execution time was roughly 5 to 1 in execution time. No need to tell which one was faster. I do understand the need of code reusability. But I do understand the need of execution efficiency too, and that is one of the main reasons why I do not and will not make some things without testing what is the real benefit (or not) and the exact results of such a change
All the best
Every indicator have limits. For example in NonLagMA I have use a prerroll for bars for algorithm get right values in init stage. But in tick event you don't need calculate many bars in almost all indicators. I commented to Madlen if he can add bars option to his indicators but he think is not useful. It's evident he don't try load 56 NonLagMAs at same time. I sent report to metaquotes because this kill MT4 ( out of memory ). It's not indicator guilty but if you can down bars to work in indicators is better...
How can the number of calculated bars limit make it calculate less than changed bars (which is usually 1), and as mladen told he makes it calculate 3 bars on a new tick? Wouldn't that be obsolete and wouldn't that just add unnecessary code?
How can the number of calculated bars limit make it calculate less than changed bars (which is usually 1), and as mladen told he makes it calculate 3 bars on a new tick? Wouldn't that be obsolete and wouldn't that just add unnecessary code?
apprentice coder
The truth is that with new builds of mt4 (started somewhere with build 900) there is a speed issue with iCustom() calls. But you are right : limiting number of bars would not change anything in that case since it has nothing in common with that issue. As of iCustom() issue : as far as I noticed, they are trying to hide the history of called custom indicators and I guess that in that calling protocol/procedure something is wrong. In build 840 everything is working just fine (still
)
braintheboss
As I explained : my indicators calculate maximum 3 bars 99.9999% of time. They could do with 2 bars on new ticks, but I prefer to calculate 3 bars (saw some examples that convinced me to do so). So there is no need at all for any "bars limitation".
As of "loading 56 NonLagMAs at a same time" : I believe that with 100K bars on a chart and with nnn charts, any trading platform will give up. Try tradestation (which is the standard for [professional trading terminals) and you shall see the same thing. Limit your charts to reasonable number of maximum bars (I never use more than 5000 bars per chart, not in the last 7-8 years of live trading, and never had any problem with that) and then try the "56 instances" - the new tick will not cause the issue, what will cause the issue is the memory usage of buffers used from indicators, but no internal limit to some maximum bars calculated in indicator will change anything regarding that when the buffer is allocated for the full chart history. There will be no change whatsoever in cases like that
___________________
So, please check what is the result of some calculations (take a simplest jurik calculation when you limit the number of calculated bars and compare it to the result with same parameters but using the whole history) and what is the real number of calculated bars in a correctly coded indicators on new ticks and then, please, check the above mentioned "issues".
___________________
PS: I did my share of testing too. The simplest price retrieval made as a class and made as a function execution time was roughly 5 to 1 in execution time. No need to tell which one was faster. I do understand the need of code reusability. But I do understand the need of execution efficiency too, and that is one of the main reasons why I do not and will not make some things without testing what is the real benefit (or not) and the exact results of such a change
All the bestFirst, you are great coder and I agree about many things but I think you are not understanding what is the problem. You forget you are loading all that indicators one time. That indicators are inside a dashboard and you have load it many times when you change settings for test new things. That is real problem. And if you have use iCustom forget have dashboard.
I use 500 bars in history and MT4 died. Its MT4 leak memory, no indicator problem. But max bars option is not for tick events ( I know that event is not CPU problem like you explained ). That option is for every time you have init indicators. Is not same calculate 500 * 56 when you load/change settings than 100* 56.
And the other problem is sometimes you cant put small history because some indicators needs bigger histories. If you use MT4 bars limits you cant control this and all indicators will use that range.
In standalone indicators bars limit is unuseful, but if you have dashboard EA is different. Please, next week you see my EA with settings in UI. This is a heavy mixer indicators signals. Every time you change settings, all indicators or a part of them will reload all, making the problem i commented before.
New version handle 5 PINs with 5 plugins ( indicators ). That means you can have 25 * 28 pairs indicators working at same time. Only load it will need time with 500 bars history. If you use SnR, then 500 bars is not enought in some cases, then you will up the max bars, slowing everything. And If I try "Averages MA" with iCustom ( 2 indicators per pair ) the thing is worst. Then max bars can help in this case.
But almost all problems are MT4, not indicators. Seeing old mql4 posted here, the code is normally optimized, then I never worry about indicators performance in tick events
Really in auto trading dashboards are the new EAs step. Currencies strength are old in forex, but how you work with them have new ways to explore.
What about data download problem when initializing (not initial calculation)?
What about data download problem when initializing (not initial calculation)?
There is a run time error that allows you to control/check that, so it is solvable by mql code
What about data download problem when initializing (not initial calculation)?
Mql5 have good API for check missing historial. Mql4 is very primitive. I have much communication with MT coders ( now I'm using newer build of metaeditor because b950 crash is large projects) and they commented me maybe MT4 will have MT5 features in a future.