a trading strategy based on Elliott Wave Theory - page 153

 
<br / translate="no"> Start, for example, from here http://forex.kbpauk.ru/showflat.php/Cat/0/Number/16113/an/0/page/2#Post16113

Vladislav, this link requires forum registration. But I tried to register on this forum 3 times already. 2 times half a year ago and now I tried it. But on all attempts to register I get an email with the following content:
**************
Your registration should be confirmed by admin before you can
login for the first time. An email will be sent to you upon confirmation of your registration. Registration is confirmed on average
on average once a day.
**************
That's all! No registration confirmation and therefore no login
***********
Login/password not found.
Unable to continue (no one knows why, don't even ask).
***********
Particularly hilarious is of course the last phrase - "(no one knows why, don't even ask)". It probably looks just genius in the eyes of the admin?!
Perhaps the administrator of the forum thinks that this phrase at the very moment when a person for the umpteenth time is trying to get access to information on their own forum, but instead of information reads this inscription will increase his credibility as the administrator, or what? The most interesting thing is that there is no one to ask - the forum does not have any e-mail for contact with the admins.

I think that perhaps new members have not registered on that forum? Like who had time to register in the past - he read the closed sections and who did not have time, respectively, too late? Is it so?
Maybe you could put in a zip file in this thread interesting pages of discussion on the above recommended link?
Thanks in advance!
 
solandr, there's always a problem with registration.
 
Perhaps you could zip-file in this thread the interesting discussion pages in the link recommended above?


Here is the page itself http://fxfilecheng.narod.ru/page.rar

And here is the attached file http://fxfilecheng.narod.ru/Pesavento_Fibonacci_Ratios.rar
 
So as not to be unsubstantiated by saying that there are errors in the MT zigzag algorithm, here is a link http://onix-trade.net/forum/index.php?s=&showtopic=118&view=findpost&p=106493
This link has an analysis of the error in the zigzag.

In order to check correctness of these conclusions, let's place in the code of zigzag after lines, where goes writing of found values to the buffer:
ExtMapBuffer[shift]=val; - writing string to the buffer
if (shift<13 && val>0) Print ("shift="+shift+" low val="+val+" Low[shift]="+Low[shift]); - check what is written there and where it is written to

ExtMapBuffer2[shift]=val;
if (shift<13 && val>0) Print ("shift="+shift+" high val="+val+" High[shift]="+High[shift]);

The check is performed on minutes and the number of bars checked can be set differently than 13

Immediately we see that the zigzag buffers contain rubbish. And everyone works with this rubbish.
Everybody thinks that the zigzag produces something correct. But in reality? The root of many systems is the zigzag. And the backbone is rotten.


Anyway, it's interesting as a programming problem - I'll have to see. By the way, did you check what is written to these cells - the evening I will have more free time myself to look. The matter is that during drawing the non-raised indicator default value is different from zero (maximum long, if I'm not mistaken) - I have been caught out by it a couple of times too. And one more thing: there are many errors in indicators (as in this one, I don't know), connected with incorrect addressing of msassives. To put it simply: wrongly counted or shifted indices: in C arrays are addressed from zero to the last element, which is not included. The most common mistake is overriding arrays. In a static layout, this will not affect the performance of the complex, as long as the program does not try to change the memory outside the data area. But what the algorithm itself sometimes generates (completely unpredictable when) cannot be used. When rewriting algorithms, which I need, I've corrected too many bugs with wrong addressing (as soon as I faced the limit in static and had to make dll dynamic layout of data arrays - here the bugs started - in VCPP you can compile programs with debugging information and at least partially localize problems).
As for the built-in zig-zag algorithm itself - for pattern search purposes it is, IMHO, unsuitable (whether straightened or native). What you need is an algorithm that will filter out swings that are significant, from the point of view of the current situation. For example, if the deviation value is less than the current "noise", then the swing is ignored immediately, if it is greater, then it is taken into account immediately and is not removed afterwards. IMHO - it's better to see everything as it was. This is for EVA purposes when trying to describe a movement in the market with one pattern 3-5, everything should be adjusted to this pattern. If we use a wider set (all Pesavento-Gartley patterns), then it doesn't really matter which pattern is identified, and that's usually the case before significant reversals. Look at my post above where I've plotted the pattern AB=CD, there was a butterfly Gartley (which was identified earlier) and we could see the levels worked out. And, to be honest, I didn't care what Elliott wave it was. What I cared about was the probability of achieving the expected levels. Regression channels help us to determine this probability, but this is the repetition of almost the entire branch.

Sincerely, Vladislav.
Good luck and good trends.
 
<br / translate="no"> In general, as a programming task interesting - will need to see. By the way, have you checked exactly what is written to these cells - I'll have more free time myself in the evening. The thing is, that on drawing the non-raised value of indicator by default is different from zero (maximum long, if I'm not mistaken) - I've been caught on it a couple of times too.


Actually, this number (2147483647 or 2 to the power of 31 minus 1 [2^31-1])
is zero. MQL-IV uses SetIndexEmptyValue() to ignore non-significant empty values.
 

Вобщем как задачка по программированию интересно - нужно будет посмотреть. Кстати, Вы не проверяли что именно пишется в эти ячейки - к вечеру будет больше свободного времени сам гляну. Дело в том, что при прорисовке нерисуемое значение индикатора по умолчанию отлично от нуля (максимальный лонг, если не ошибаюсь)- я на этом тоже пару раз попадался.


This number (2147483647 or 2 to the power of 31 minus 1 [2^31-1])
is actually zero. In MQL-IV, SetIndexEmptyValue() is used to prevent empty, insignificant values.


I decided to add it. This number (2147483647) usually appears in the following situation:
1) An indicator is written that has at least one indicator buffer
2) Non-index values are suppressed by SetIndexEmptyValue(), but
3) Empty values are not filled forcibly with null value

Result: the indicator works correctly when looking at a chart, but when you start applying to such an indicator an errored index from another indicator or an EA, miracles happen - this number 2147483647 is output. If you have experience - you start to fix this algorithmic error in the indicator code, if not - you start looking for a black cat in a dark room, while the cat itself isn't present. But it is still useful to look for it - it is called experience and it sticks firmly in your .... memory :)
 

Вобщем как задачка по программированию интересно - нужно будет посмотреть. Кстати, Вы не проверяли что именно пишется в эти ячейки - к вечеру будет больше свободного времени сам гляну. Дело в том, что при прорисовке нерисуемое значение индикатора по умолчанию отлично от нуля (максимальный лонг, если не ошибаюсь)- я на этом тоже пару раз попадался.


This number (2147483647 or 2 to the power of 31 minus 1 [2^31-1])
is zero. In MQL-IV, SetIndexEmptyValue() is used to avoid empty, insignificant values.



With all due respect, 2 to the power +31 cannot be one in any case. This equality can be fulfilled only through bit depth limitation. What will you do when the digit capacity changes? If the array is initialized with zero, then it must be zero, if not, then it must be specified that the result is undefined. After all, the developers themselves referred to the CPP standard. Although I do everything easier: I need zero - I force zero.

Regards, Vladislav.
Good luck and good trends.
SZY 2 Rosh - read the addendum. As far as I remember, such an effect (2147483647 instead of zero) occured without suppression of the default SetIndexEmptyValue() function, I may be mistaken - it happened long ago. I also got back to my old habit from C programming days - to initialize everything (zero or any other needed value) by force - usually it saves much time and it is a shame without it :). Since then this problem doesn't bother me - I just remembered how I came across it myself.
 
Multiply 2 by 31 and subtract one from the result - that's what I meant (Answer : 2147483647 ). Check in Excel. The 32nd bit is reserved for a number sign (plus or minus)
 
<br/ translate="no"> With all due respect, but in fact 2 to the power of +31 in the general case can in no way be one. This equality can only be fulfilled due to data digit capacity constraint. What will you do when the digit capacity changes? If the array is initialized with zero, it must be zero, if not, then it must be specified that the result is undefined. After all, the developers themselves referred to the CPP standard. Although I do everything easier: I need zero - I force zero.



I wasn't talking about initialization with an initial value(ArrayInitialize() function) but about suppressing output of null or uninitialized (often effect-dynamic) values (SetIndexEmptyValue() functions) . These functions are not equivalent to each other.
 
Multiply 2 by 31 and subtract one from the result - that's what I meant. Check in Excel. The 32nd bit is reserved for a number sign (plus or minus) <br/ translate="no">


Only for sign, not for ensigns. And for data like longsigns ? I say - what will you do when you change the digit capacity of the data ? The technology is developing rather quickly and during migration to 64-bit buses the dimensionality of int-type variables will change - according to the standard PSA it depends on the dimensionality of the data bus and is limited by the minimum value (not maximum), so not only int, but long range may change too. These are strictly one-byte chars. They invented standards for something, didn't they? One reason is the compatibility of programs.

Regards, Vladislav.
Good luck and good trends.
Reason: