Demonstrating the cluster approach to market... - page 4
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
Condition for an open position upwards:
if (Ind_0 > 0 && Ind_1 < 0)
Condition for closing an open position upwards:
if (Ind_0 <= 0)
Condition for opening a position downwards:
if (Ind_0 < 0 && Ind_1 > 0)
Condition for closing an open downward position:
if (Ind_0 >= 0)
The terms are controversial and not based on statistics: it is not enough to have just a positive sign for the first currency index and a negative sign for the second currency to open a long. There will be too many false entries.
Besides, it is not clear why to close an open position it is sufficient to consider the sign of the index of only one currency.
And sab1uk also correctly points out that synthetic crosses on small TFs will seriously differ from real ones.
P.S. I haven't looked at the code yet, but I'm trying to do something similar myself. It seems that Semenych's approach is fundamentally different, as he suggests to open on rebound and not on breakout, as here?
I think the strongest signal will be when one index reaches its maximum ( absolute value) and turns in the opposite direction, and then the second index must also turn... this is the strongest signal, which should show the reversal of the main direction of movement in the current timeframe... If there is no such signal, then you can rely on a weaker signal - crossing the index chart, but before the crossing, the charts should have a pronounced change dynamics, not that they crawled "side by side in the flux
If you want to use a different signal in the same way as above, you have to create a different signal.
The conditions are controversial and are not based on statistics: it is not enough to have just a positive sign for the first currency index and a negative sign for the second currency to open a long. There will be too many false entries.
Also, it is not clear why it is sufficient to take into account only one currency index sign to close an open position.
And sab1uk also correctly points out that synthetic crosses on small TFs will be seriously different from real ones.
P.S. I haven't looked at the code yet, but I'm trying to do something similar myself. It seems Semenych's approach is fundamentally different, because he suggests to open on rebound and not on breakout as here?
CL1i - this indicator shows the difference between "cluster prices" of the base currency and the quote of the instrument on which it is running.
Thus,
Ind_0 is the difference between the "cluster prices" of the base currency and the quote currency of the instrument on bar 0 - current bar
Ind_1 is the difference between "cluster prices" of the base currency and quote currency of the instrument on bar 1 - the first bar passed
It turns out then, that we open up, for example, at the very first moment when the "cluster price" of the base currency starts to exceed the "cluster price" of the quoted currency.
I assure YOU, Semen Semenych has the same system of opening/closing positions.
on minute timeframes synthetic pairs will have discrepancies with natural pairs
Tried all available "natural" instruments (with only GBPNZD missing crosses),
However, the load on the computer was such that it was almost impossible to work.
Получается тогда, мы открываемся, к примеру, вверх, в самый первый момент, когда "кластерная цена" базовой валюты начинает превышать "кластерную цену" котировочной валюты.
Ah, there you go. Thanks, ssd.
However, the load on the computer was such that it was almost impossible to work.
Well, of course it's workable. The trick is the amount of history uploaded. You don't need much of it. And the calculations there are very simple, even a single-core can handle them. Well, of course, if you don't calculate on every tick.
But my input criterion is not that cloudy. If you are interested, drop me a line and we'll discuss.
Tried all available "natural" tools (with modelling through crosses only missing tool GBPNZD),
however, the load on the computer was such that it was almost impossible to work.
Using cyclic buffers for calculations reduces the load
Ah, there you go. Thanks, ssd.
Why, it is possible to work. The trick is in the volume of downloaded history. You don't need much of it. What do you need minutes for a few years with this system?
That's right, a long story with this approach is kind of unnecessary.
However, the frequency of the "error" - ERR_HISTORY_WILL_UPDATED 4066 was such that there was uncertainty in the indicator readings.
In other words, the load on the computer was actually small, the waiting time for paging tools was slowing down all the work.
Keeping all 28 tools open is very inconvenient.
Here's a thread where the developers have given advice on how to deal with it. And you don't need to keep all the tools open. It is enough to have them in Market Watch.
Once again: you do not need to count everything on every tick. It is redundant for this system. It is enough to address the calculations, say, once a minute. But moreover, it is desirable to simply access each symbol - for example, simply by iClose().
Here's a thread where the developers have given advice on how to deal with it.
>> Yes, that's it! >> Thanks, I'll have a look.
Tried all available "natural" tools (with modelling through crosses only of the missing GBPNZD tool),
However, the load on the computer was such that it was almost impossible to work.
Had the same problem. It took three years to optimise.
Now it counts in 5 seconds what used to take 5 minutes.