
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
Thank you... I found the relevant chapter in the book. By the way, if anyone ever finds a bug in my code of any degree of antiquity, I'd be grateful if you could poke me in it... in case I missed it. :-)
PS: I'll try to ask fewer questions. :-)
In general, I think such programming trifles are not worth discussing in this thread.
Yes, they are.
Because I don't understand the necessity of checking if(size-2!=0) - this is one.
And although I vaguely recall using sampling estimates and won't argue strongly against disper=disper/(size-2) (instead of disper=disper/(size)) , I'm sure there's no point in sharpening the forumula(i.e. there's no difference between the two in this case) - that's two.
I'm not a mathematician, but it seems to me that with a size tending towards infinity the variance will tend towards 0... So if you're estimating a sample of 400 bars, then whether you subtract 1 or 2 from them, or don't subtract anything at all, the final result won't be greatly affected... Nevertheless, the formula is a formula, and if my uncle wrote "N-2" in a smart book, then personally I'm inclined to follow his advice... :-)
In principle of course this condition is completely unnecessary.
I just did it when writing the code originally - I removed the check before division, as 0 cannot be because the sample is obviously larger. But then as the code developed, errors of division by zero started occurring from time to time. Since there is no debugger in MT4, it was difficult to find out where this zero has occurred. And until I implemented the condition of checking the division by zero in all divisions, I didn't manage to understand exactly in what division zero was found! Well, in the future, of course, you can remove this unnecessary check. Although I doubt that it will give any gain in time of calculation, because basic time is spent on calculation itself, but not on some superfluous checks of code stability.
There is no fundamental difference in these formulas for our problem and the final profit is unlikely to be affected in any noticeable way. But why not do everything in full compliance with how it should be according to mathematics? We in the Vladislava system are just trying to get away from subjectivity and get the most objective assessment of the current market situation based on mathematical methods.
You are right! But only in the first part of your statement ;o)))
So, right now you can clearly see the difference - if you set the first parameter to true, you will get octaves according to the old algorithm, that is, using built-in functions to search for extrema.
If you set it to false (default setting), you will get, IMHO, what you need. The difference is as follows. Extrema are defined for the definition of the sample - the highest High and lowest Low at a given area. This ensures that we have a minimum probability of capturing part of the over trend. It is then compared with the Highest/Lowest value on the last bars - that is only on one side of the given range - if we are in a trend we can easily break through the set levels and we will need to rebuild the octaves in time.
Good luck and good trends.
HZZ there was a mistake - I have rewritten the code - now the difference is not so noticeable :).
И хотя я смутно вспоминаю использование оценок по выборке и не буду сильно спорить против disper=disper/(size-2) (вместо disper=disper/(size)) , уверен, что нет смысла затачивать форумулу(то есть, разницы между ними нет в данном случае) - это два.
In principle, of course, this condition is completely unnecessary.
When I was writing the code, I originally did so - I removed the check before division, because 0 cannot be because the sample is obviously larger. But then as the code developed, errors of division by zero started occurring from time to time. Since there is no debugger in MT4, it was difficult to find out where this zero has occurred. And until I checked the condition of checking the division by zero in all divisions, I failed to understand exactly in what division zero was found! Well, in the future, of course, you can remove this extra check. Although I doubt that it will give any gain in time of calculation, because basic time is spent on calculation itself, but not on some superfluous checks of code stability.
There is no fundamental difference in these formulas for our problem and the final profit is unlikely to be affected in any noticeable way. But why not do everything in full compliance with how it should be according to mathematics? We in the Vladislava system are just trying to get away from the subjectivity and get the most objective assessment of the current market situation based on mathematical methods.
In fact, there is no difference at all, as the error is negligible, but everyone can, of course, count in their own way.
Indeed, we can now see the difference in the performance of the indicator.
Thank you very much for the improvement! Now the phrase "all levels are normalized to the daily timeframe" has probably received its full implementation in the finalized indicator.
please see how correct this situation is? USDCAD H4, offset 40.
https://c.mql5.com/mql4/forum/2006/06/new_indicator.zip
You can see how the price went one and a half figures below the lowest indicator line. Shouldn't it be like that?
https://c.mql5.com/mql4/forum/2006/06/new_indicator.zip
You can see that the price has moved a figure and a half below the lowest indicator line. Shouldn't it be like this?
No, it shouldn't. Sorry - there was an error there - the result of a typo - when comparing to the right edge of the range. I have corrected it. Now the differences are not so noticeable :). There instead of the bar number of extreme High for High took the bar number of extreme Low. Discovered it when I started racing through the story in detail.
I'll rearrange the codes.
Good luck and happy trends.
ZS re-hung.