A robot without indicators - page 6
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
There are indicators that determine...not a trend or a flat...they do not exist in pure form anyway. They determine the advantage of forces on the buy or sell in general in either direction. You cannot determine it with your eyes. Because it's not the price direction, but the degree of entropy (randomness) in the price. In fact these indicators are something like inventions that is why they are not popular, of course I have a couple of them developed on request in personal communication. I will not be able to determine the trend a priori. But a flat is quite possible. Since flat + randomness exists about 98% of all market time.
A flat does not exist 98% of the time, it exists exactly as long as there is a trend. The market changes from a trend to a flat, the distribution law fluctuates but never becomes a normal distribution. If the flat was 98% of the time, it would be too easy to make money on it.
A flat does not exist 98% of the time, it exists as long as there is a trend. The nature of the market changes from trendy to flat, the law of distribution fluctuates around normal, but never becomes so. If a flat were 98% of the time, it would be too easy to make money on it.
1. Please watch your emotions.
You know, you remind me of the category of people who ask for proof, and after presenting such proof they say the following "your proof, not....".
What can I say to this "says only about a non-optimal indicator code", you are right, in your understanding the optimal code is... I don't even want to guess what it is.
Maybe you missed something, but I initially wrote that putting all the logic in the Expert Advisor's code is not a good solution provided N number of instruments is opened and loaded in the terminal, because in my opinion the Expert Advisor's task is to manage orders in time.
What I have shown, and you commented "about non-optimal indicator code" (I'm not saying otherwise), provided a couple of instruments are open and a couple of bots and indicators, I don't see such lags, that is, if we follow your logic, about the "optimal" code, messages like"indicator is too slow" will never appear, if 10 or more instruments are open, do you seriously believe in it?
From personal experience I came to a conclusion that all "heavy" calculations should be done in a separate program so as not to observe similar lags, and MQL will be responsible for the task of serving orders based on commands received from the program which does not directly affect MQL engine and its productivity. As a matter of fact, I'm doing it now.
Actually, I have nothing to prove, since you haven't encountered it, so:
1. You are a god in the world of programming :);
2. You just haven't written anything serious yet.
3. You're just rating yourself with your hacks.
You know, you remind me of the category of people who ask for proof, and after presenting such proof they say the following "your proof, not proof....".
What can I say to this "only speaks of a non-optimal indicator code", you are right, in your understanding the optimal code is... I don't even want to guess what it is.
Maybe you missed something, but I initially wrote that putting all the logic in the Expert Advisor's code is not a good solution provided N number of instruments is opened and loaded in the terminal, because in my opinion the Expert Advisor's task is to manage orders in time.
What I have shown, and you commented "about non-optimal indicator code" (I'm not claiming otherwise), provided that a couple of instruments and a couple of bots and indicators are open, I don't see such lags, that is, if we follow your logic, about the "optimal" code, messages like"indicator is too slow" will never appear, if 10 or more instruments are open, do you seriously believe in it?
From personal experience I came to a conclusion that all "heavy" calculations should be done in a separate program so as not to observe similar lags, and MQL should be entrusted with servicing orders based on commands received from the program which does not directly affect MQL engine and its productivity. As a matter of fact, I'm doing it now.
Actually, I have nothing to prove, since you haven't encountered it, so:
1. You are a god in the world of programming :);
2. You just haven't written anything serious yet.
3. You're just rating yourself with your hates.
A flat does not exist 98% of the time, it exists as long as there is a trend. The nature of the market changes from trendy to flat, the law of distribution fluctuates around normal, but never becomes so. If a flat were 98% of the time, it would be too easy to make money on it.
In case you haven't noticed... "flat+random". That's what makes up 98% of the time.
And trends...are just outliers...market anomalies...they happen rarely such as Brexit in the UK. Of course, there was a real selling trend there.
These "trends" cannot be detected without a high-speed link to the exchange. There is also a mathematical tool that should be invented. And mind you, no one here says, but the trend itself may also be random =) It sounds absurd, but it does not stop being true.)
In case you haven't noticed... "flat+random". That's what makes up 98% of the time.
And trends...are just spikes...market anomalies...they happen rarely, such as Brexit in the UK. Of course, there was a real selling trend there.
These "trends" cannot be detected without a high-speed link to the exchange. There is also a mathematical tool that should be invented. And mind you, no one here says, but the trend itself may also be random =) It sounds absurd but it doesn't stop being true.)
Let me explain in another way. If the probability of reversal is 50%, then it is not a trend and not a flat, but the price will still move somewhere. In that case the chart will have a normal probability distribution (as a random process). But in the market, the probability of a reversal is mostly less than 50% is a trend, or more than 50% is a pullback. But if taken over a long period of time, the probability of reversal is around 50%. So the market fluctuates around this value. Here I'm talking about forex and the major 28 pairs. It's a little bit different on the fund.
You know, you remind me of the category of people who ask for proof, and after presenting such proof they say the following "your proof, not proof....".
What can I say to this "only speaks of a non-optimal indicator code", you are right, in your understanding the optimal code is... I don't even want to guess what it is.
Maybe you missed something, but I initially wrote that putting all the logic in the Expert Advisor's code is not a good solution provided N number of instruments is opened and loaded in the terminal, because in my opinion the Expert Advisor's task is to manage orders in time.
What I have shown, and you commented "about non-optimal indicator code" (I'm not saying otherwise), provided that a couple of instruments and a couple of bots and indicators are open, I don't see such lags, that is, if we follow your logic, about the "optimal" code, messages like"indicator is too slow" will never appear, if 10 or more instruments are open, do you seriously believe in it?
From personal experience I came to a conclusion that all "heavy" calculations should be done in a separate program so as not to observe similar lags, and MQL should be entrusted with servicing orders based on commands received from the program which does not directly affect MQL engine and its productivity. As a matter of fact, I'm doing it now.
Actually, I have nothing to prove, since you haven't encountered it, so:
1. You are a god in the world of programming :);
2. You just haven't written anything serious yet.
3. You're just rating yourself with your hacks.
Learn to write code properly. You have only yourself to blame for your lags. I've been here more than 10 years, and I've written only one indicator with such a message. However, I corrected it myself.
Of course, I have a lot of your experience...
But please give me the code of the indicator that hangs your thread.
You know, you remind me of the category of people who ask for proof, and after presenting such proof they say the following "your proof, not proof....".
What can I say to this "only speaks of a non-optimal indicator code", you are right, in your understanding the optimal code is... I don't even want to guess what it is.
Maybe you missed something, but I initially wrote that putting all the logic in the Expert Advisor's code is not a good solution provided N number of instruments is opened and loaded in the terminal, because in my opinion the Expert Advisor's task is to manage orders in time.
What I have shown, and you commented "about non-optimal indicator code" (I'm not saying otherwise), provided a couple of instruments are open and a couple of bots and indicators, I don't see such lags, that is, if we follow your logic, about the "optimal" code, messages like"indicator is too slow" will never appear, if 10 or more instruments are open, do you seriously believe in it?
From personal experience I came to a conclusion that all "heavy" calculations should be done in a separate program so as not to observe similar lags, and MQL should be entrusted with servicing orders based on commands received from the program which does not directly affect MQL engine and its productivity. As a matter of fact, I'm doing it now.
Actually, I have nothing to prove, since you haven't encountered it, so:
1. You are a god in the world of programming :);
2. You just haven't written anything serious yet.
3. You're just making a rating for yourself with your hacks.
Answer:
Forum on trading, automated trading systems and trading strategy testing
My robot without indicators
Artyom Trishkin, 2018.09.27 15:42
I think it is quite correct (tolerant), the example of calculation of the whole indicator, and one optimized part from it, the optimization gives a gain of 1-2 orders of magnitude:
If all bars are recalculated on every tick (probably 99% of kodobase), you will get a message about a slow indicator. Calling icustom calculates all the bars.
Learn to write the code correctly. You have only yourself to blame for your brakes. I've been here more than 10 years, and I've written only one indicator with such a message. However, I corrected it myself.
Of course I have a lot of experience in this field...
But please give me the code of indicator which hangs your thread.
You don't get it...
It's sad... There is just an algorithm, which you are dealing with, and there is an analysis of a large amount of data, and no matter how you optimize your code, you can not get away from it, as examples I cite miners, you think there is a code problem, that you need mega-computers????
So, I just warned you in my post, while you tried to play smart. This is the end of the discussion, it makes no sense.